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ABSTRACT 
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software  integration,  training  repetition,  and  performance  feedback  necessary  to  prepare 
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Naval  Aviation  Warfighting  Development  Center 

Navy  Enlisted  Classification 

Naval  Integrated  Fire  Control-Counter  Air 
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NIFC-CU 

NPS 

NSWDC 

NTSP 

NWDC 

OA 

OFRP 

OMOE 

OPNAV 

OPNAV  N9 

OPNAV  N9I 

OTH 

PBED 

RSAF 

SEA 

SME 

SMWDC 

SNA 

swo 

TDSI 

TRE 

TTG/L/P 

TTP 

TYCOM 


Naval  Integrated  Fire  Control-Counter  Undersea 

Naval  Postgraduate  School 

Naval  Surface  Warfighting  Development  Center 

Navy  Training  Systems  Plan 

Naval  Warfare  Development  Center 

Operational  Activity 

Optimized  Fleet  Response  Plan 

Overall  Measure  of  Effectiveness 

Office  of  the  Chief  of  Naval  Operations 

Deputy  Chief  of  Naval  Operations  for  Warfare  Systems 

Deputy  Chief  of  Naval  Operations  for  Warfare  Systems 
Integration 

Over-the-Horizon 
Plan,  Brief,  Execute,  Debrief 
Republic  of  Singapore  Air  Force 
Systems  Engineering  Analysis 
Subject  Matter  Expert 

Naval  Surface  and  Mine  Warfighting  Development  Center 

Student  Naval  Aviator 

Surface  Warfare  Officer 

Temasek  Defense  Systems  Institute 

Tactical  Readiness  Examination 

Tactical  Training  Group,  Atlantic/Pacific 

Tactics,  Techniques,  and  Procedures 

Type  Commander 


UHF 

Ultra-High  Frequency 

USFF 

United  States  Fleet  Forces 

USMC 

United  States  Marine  Corps 

USN 

United  States  Navy 

usv 

Unmanned  Surface  Vehicle 

VHF 

Very-High  Frequency 

VR 

Virtual  Reality 

WDC 

Warfare  Development  Center 

WFTS 

Webfires  Training  System 

WIC 

Warfare  Innovation  Continuum 

WTI 

Weapons  and  Tactics  Instructor 
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EXECUTIVE  SUMMARY 


The  nature  of  naval  warfare  is  continuously  evolving.  The  traditional  kill  chain 
approach  is  expected  to  be  insufficient  to  neutralize  near-peer  threats  in  the  future.  To 
increase  the  combat  effectiveness  of  the  U.S.  Navy  in  a  future  combat  environment,  the 
Navy  is  shifting  its  warfighting  approach  to  a  kill  web,  or  webfires,  concept  of 
operations.  In  his  2016  interview  with  the  U.S.  Naval  Institute,  Admiral  Manazir  postures 
that  unlike  the  current  kill  chain  process  in  which  units  are  limited  to  engagements 
utilizing  organic  sensor  data,  future  units  will  instead  be  able  to  work  together  to  “create 
a  cross-domain  kill  web”  able  to  share  combat-relevant  data  for  the  purpose  of  tracking 
and  engaging  an  adversary.  This  shift  in  the  way  the  Navy  fights  calls  for  a  new  approach 
to  training  the  Navy’s  future  warfighter.  This  report  details  a  systems  engineering 
approach  for  developing  a  webfires  training  system  (WFTS)  to  prepare  the  future 
warfighter  for  an  engagement  with  a  near-peer  threat. 

A.  SCOPE  AND  ASSUMPTIONS 

Due  to  time  constraints  and  still-maturing  Webfires  concepts,  the  team  applied 
some  significant  assumptions  and  boundaries  to  scope  the  problem  to  a  manageable  level. 
These  assumptions  allowed  the  team  to  focus  their  efforts  into  determining  capability 
gaps  in  the  Navy’s  current  training  system,  generating  a  base  list  of  requirements  for  the 
future  WFTS  to  meet,  identifying  key  software/hardware  capabilities,  selecting  the  main 
organizations  that  will  support  training  and  their  tasks,  and  research  technology  that  will 
support  these  functions  and  organizations.  Completion  of  these  tasks  allowed  the  team  to 
build  a  foundation  upon  which  a  full  system  architecture  can  be  built  in  the  future. 

B.  CAPABILITY  GAPS 

Stakeholder  Analysis  identified  four  key  capability  gaps:  the  absence  of  any 
webfires  concept  training  today,  a  lack  of  multi-unit  training  repetition  to  support  high- 
velocity  learning,  a  lack  of  compatible  networks  to  support  integration  of  units  and 
simulators  for  webfires  training,  and  a  lack  a  quality  feedback  to  facilitate  high-velocity 
learning. 
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The  Navy  is  currently  developing  the  webfires  concept.  The  recent  deployment  of 
the  first  capable  Naval  Integrated  Fire  Control  -  Counter  Air  (NIFC-CA)  strike  group 
demonstrates  that  such  a  concept  is  being  developed  and  implemented  by  the  fleet.  The 
implementation  of  NIFC-CA  is  just  one  small  aspect  of  the  webfires  concept.  If  all 
Carrier  Strike  Group  or  Expeditionary  Strike  Group  (CSG/ESG)  units  are  able  to  share 
fire  control  data  with  each  other,  then  the  webfires  concept  can  be  implemented  across 
the  air,  surface,  and  undersea  warfare  domains,  which  is  consistent  with  Admiral 
Manazir’s  vision  for  networked  warfare  as  discussed  with  the  U.S.  Naval  Institute  in 
September  2016.  For  warfighters  to  implement  this  advanced  weapons  system 
effectively,  they  require  doctrine.  This  capstone  report  recommends  that  the  Naval 
Warfare  Development  Center  (NWDC)  coordinate  with  the  other  warfare  development 
centers  to  document  a  unified  set  of  tactics,  techniques,  and  procedures  (TTPs)  that  are 
used  by  all  warfighters  to  implement  and  train  for  webfires. 

Additionally,  the  network  capability  of  today’s  training  system  is  not  robust 
enough  to  support  the  repetition  necessary  to  facilitate  high-velocity  learning  and  in  turn 
results  in  less  efficient  multi-unit  training.  Currently,  the  only  complete  CSG/ESG  multi¬ 
unit  training  is  performed  during  Composite  Training  Unit  Exercises  (COMPTUEX) 
within  the  integrated  phase  of  the  Optimized  Fleet  Response  Plan  (OFRP)  to  certify  a 
CSG  or  ESG  for  deployment  and  entry  into  the  sustainment  phase  of  the  OFRP. 
Currently,  the  Tactical  Training  Groups  (TTG)  have  the  ability  to  facilitate  fleet  synthetic 
training  (FST)  events  prior  to  COMPTUEX.  However,  due  to  the  nature  of  the  training 
network  and  the  reliance  on  large  numbers  of  people  to  conduct  these  FST  events,  the 
TTGs  can  only  perform  one  simulation  at  a  time.  A  more  robust,  decentralized  training 
network  along  with  a  database  of  preprogrammed  training  simulations  will  greatly 
increase  the  potential  for  more  frequent  integrated  training. 

Lastly,  repetition  is  only  one  aspect  of  high-velocity  learning.  For  high-velocity 
learning  to  work,  training  must  be  current,  accurate,  and  relevant.  This  report 
recommends  that  the  future  WFTS  collect  and  produce  data  that  is  used  by  the  NWDC  to 
assess  the  current  engagement  doctrine.  By  incorporating  a  feedback  loop  into  the 
training  system,  the  doctrine  can  be  updated  to  reflect  better  approaches  to  attack  an 


enemy  during  the  training  process,  and  correct  deficiencies  discovered  in  the  doctrine. 
Additionally,  the  collected  data  may  be  used  by  the  appropriate  teams  in  certifying  and 
evaluating  units  for  deployment.  This  could  potentially  reduce  training  and  certification 
requirements.  However,  for  this  feedback  loop  to  work,  the  NWDC,  along  with  the 
certification  and  evaluation  teams,  must  establish  well-defined  data  collection 
requirements. 

C.  REQUIREMENTS 

Based  on  the  identified  Capability  Gaps,  the  team  developed  the  following 
capability  requirements  for  the  WFTS: 

1.  Webfires  Concept  Training  Requirements 

a.  Fit  into  the  basic,  integrated,  and  sustainment  phases  of  the  OFRP 

b.  Integrate  training  during  both  unit  and  multi-unit  training 

c.  Integrate  training  during  in-port  and  at-sea 

2.  Repetition  Requirements 

a.  Provide  standardized  training  scenarios  for  unit  and  multi-unit  training 

b.  Provide  training  capability  in  a  limited  communication  environment 

c.  Capable  of  allowing  units  and  simulators  to  independently  establish 
their  own  training  networks  for  simulation. 

d.  Shall  integrate  with  future  strike  group  units’  networks,  training 
facilities,  and  simulators 

3.  Feedback  Requirements 

a.  Provide  data  that  can  be  used  to  assess  doctrine  against  a  near-peer 
threat 

b.  Provide  data  that  can  be  used  to  aid  certification  and  evaluation  of 
units  during  the  OFRP. 
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D.  FUNCTIONAL  ANALYSIS 


The  functional  analysis  identified  key  functions  that  the  future  training  system 
must  meet  in  order  to  satisfy  capability  requirements  and  fill  capability  gaps.  The 
functional  analysis  looked  at  both  hardware/software  function  and  organization  functions/ 
responsibilities  that  are  performed.  Most  notably,  this  report  identifies  the  key 
organizations  that  will  be  involved  in  this  future  training  system  and  their  tasks.  Those 
organizations  are  the  Intelligence  Community,  NWDC,  TTGs,  Numbered  Fleets,  CSG-4/ 
15,  Operational  Strike  Group  Commanders,  CSG/ESG  Units,  and  their  embedded 
simulators.  These  organizations  must  jointly  produce  effective  webfires  training 
objectives  to  create  future  simulations  that  will  aid  CSG/ESG  unit  training  to  a  near-peer 
threat  level.  Additionally,  these  organizations  must  establish  effective  data  requirements 
that  the  WFTS  must  meet  in  order  to  aid  certification  and  evaluation  and  allow  the 
NWDC  to  assess  webfires  doctrine  and  update  it  accordingly. 

E.  SYSTEM  ARCHITECTURE 

This  report  develops  a  foundation  upon  which  a  more  in-depth  system 
architecture  can  be  produced  once  webfires  systems  components  are  online.  The  most 
significant  aspect  of  this  foundation  is  the  identification  of  the  Nodes,  Operational 
Activities,  Functions,  and  enabling  Components.  Figure  1  shows  the  process  used  to 
design  and  create  this  foundation. 

•  Nodes  are  the  organizations  that  are  involved  in  this  training  system. 

•  Operational  activities  are  the  tasks  that  the  organizations  have  to  perform 
in  order  to  support  training,  increase  repetition,  and  provide  high-velocity 
learning. 

•  Functions  support  and  enable  the  operational  activities. 

•  Functions  are  performed  by  components. 
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Adapted  from  CORE  Architecture  Definition  Guide  (DoDAF  v2.02) 
Figure  1.  WFTS  Foundational  Architecture  Flow 


F.  WFTS  RECOMMENDED  TECHNOLOGIES 

Since  the  webfires  concept  is  still  in  its  infancy,  this  project  focuses  on  general 
technological  capabilities  that  the  WFTS  components  must  possess  to  facilitate  repetition, 
high-velocity  learning,  and  performance  feedback.  Using  an  analysis  of  alternatives 
approach,  this  report  identifies  the  technologies  that  would  be  most  useful  in  comprising 
the  WFTS.  These  significant  technologies  are: 

•  Artificial  intelligence  systems  or  automated  systems  to  play  red  forces 
during  simulations. 

•  An  advanced  mesh  network  topology. 

Current  multi-unit  simulations  conducted  by  the  Navy  are  people-intensive. 
Simulations  require  a  large  number  of  personnel  to  play  the  red  force.  This  in  turn  limits 
the  number  and  the  frequency  of  quality  simulations  that  are  performed  at  any  given  time. 
By  augmenting  simulations  with  a  red  force  played  by  some  sort  of  artificial  intelligence 
or  automated  responses,  the  quality  and  quantity  of  training  can  be  increased. 
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The  current  training  network  is  essentially  comprised  of  a  star  network  topology 
with  the  TTGs  acting  as  the  central  node  to  coordinate  and  connect  units  and  simulators 
to  the  training  network.  To  increase  training  repetition  and  high-velocity  learning  for 
units  in  port  and  at  sea  along  with  the  incorporation  of  land-based  simulators,  a  more 
decentralized  network  topology  is  needed.  The  difficulty  of  implementing  a  mesh  training 
network  is  compounded  by  information  assurance  issues,  lack  of  sufficient  network 
connections,  and  lack  of  sufficient  training  network  interfaces  to  stimulate  combat 
systems  on  ships. 

G.  ANALYSIS  OF  ALTERNATIVES 

A  morphological  box  is  used  in  this  study  to  develop  nine  design  alternatives. 
These  nine  design  alternatives  were  developed  to  showcase  nine  different  aspects  the 
WFTS  should  be  capable  of  performing.  Qualitative  comparisons  are  used  to  rank  each  of 
the  nine  alternatives.  These  alternatives  helped  the  team  determine  which  aspects  of  the 
WFTS  may  provide  the  biggest  benefits  for  a  training  system  focused  on  high-velocity 
learning.  The  analysis  and  alternatives  section  in  the  report  discusses  each  of  the  nine 
alternatives  and  the  results  of  all  comparisons.  The  intent  in  comparing  alternatives  was 
not  to  limit  selection  to  one  finalized  recommended  design,  but  rather  to  highlight 
additional  possibilities  regarding  capabilities  and  limitations  to  use  for  further  research 
and  development  of  the  WFTS. 

H.  ITEMS  FOR  FURTHER  RESEARCH 

Through  research  and  stakeholder  interviews,  the  authors  discovered  multiple 
relevant  topics  with  respect  to  training,  webfires,  and  webfires  training.  Due  to  time 
constraints  and  project  scope,  the  team  was  unable  to  explore  many  of  these  extremely 
relevant  topics.  However,  these  topics  are  important  for  implementing  webfires, 
advancing  the  implementation  of  a  WFTS,  and  improving  warfighter  training  in  general. 
This  report  recommends  that  further  research  on  the  following  topics  would  be  in  the  best 
interest  of  the  Navy: 


Communication  network  advancement. 


•  Artificial  intelligence  and  machine  learning. 

•  Navy  Training  Systems  Plan  for  the  WFTS. 

•  Technology  to  augment  face-to-face  briefing  and  debriefing. 

•  Information  assurance. 

•  The  importance  and  incorporation  of  more  SMEs  in  the  training  process. 

I.  CONCLUSIONS 

The  key  to  providing  high-velocity  learning  is  increasing  repetition,  providing 
effective  feedback,  and  providing  quality  training.  The  future  WFTS  will  provide  high- 
velocity  learning  by  incorporating  rapid  data  feedback,  simulations,  and  increased 
connectivity. 

•  Clear  data  collection,  processing,  and  distribution  requirements  must  be 
established 

•  Investment  into  being  able  to  provide  simulations  using  real  warfighting 
equipment  must  be  made  to  increase  the  quality  of  training 

•  Information  Assurance  requirements,  network  topology,  and 
communications  bandwidth  limitations  must  be  addressed  to  allow  more 
repetition  and  repeatability 
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I. 


INTRODUCTION 


The  United  States  Navy  (USN)  has  been  the  cornerstone  of  the  nation’s  power 
projection  and  security  for  over  240  years.  To  sustain  such  an  obligation  under  an  ever- 
changing  and  dynamic  environment,  the  Navy  must  develop  the  concepts  and  capabilities 
to  provide  our  national  leaders  with  options  for  handling  situations  ranging  from  non¬ 
conflict  stability  operations  to  near-peer  combat  at  sea. 

Current  combat  systems  are  often  closely  linked  among  the  various  forces  of  a 
strike  group.  The  concept  of  integrating  unmanned  systems  into  distributed  lethality  and 
the  ability  to  communicate  among  distant  forces  to  provide  overwhelming  offensive 
firepower  against  an  adversary  was  evaluated  in  a  previous  systems  engineering  analysis 
capstone  report  (Erstad  et  al.  2016).  The  distributed  lethality  construct  rapidly  expanded 
into  the  proposed  webfires  concept,  which  integrates  the  air,  surface,  and  sub-surface 
domains  in  a  highly-connected  network  to  achieve  unparalleled  communication  and  fire- 
support  abilities  among  the  various  elements  of  a  strike  group.  Systems  Engineering 
Analysis  Cohort  25,  collectively  referred  to  as  “the  team”  for  the  remainder  of  the  report, 
was  tasked  to  develop  a  training  architecture  to  enable  the  adoption  of  the  previously 
described  webfires  concept.  This  architecture  will  leverage  the  potential  technologies  of 
the  2025  to  2030  timeframe  and  use  the  principles  of  high-velocity  learning  as  the 
foundation  of  the  training  system. 

A.  ORGANIZATION  OF  THE  REPORT 

The  entire  project  is  documented  in  12  chapters.  These  chapters  are  organized  in  a 
way  that  mirrors  the  process  the  team  followed  to  create  the  training  system  architecture. 
The  team  began  by  examining  several  systems  engineering  process  models,  which  are 
described  in  a  later  section  of  this  chapter,  and  chose  an  appropriate  systems  design 
approach.  The  report  follows  the  team’s  efforts  to  understand  the  problem,  identify  and 
analyze  gaps,  generate  system  architectures,  and  ultimately  recommend  a  comprehensive 
design  that  is  not  only  appropriate  to  the  tasking,  but  also  satisfies  the  stakeholders’ 
needs. 
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The  first  three  chapters  provide  for  the  framework  and  context  of  the  problem. 
Chapter  I,  “Introduction,”  provides  an  overview  of  the  project,  including  project 
background,  project  team,  the  foundations  on  which  the  project  is  built,  systems 
engineering  process  models,  and  system  design  approach.  Chapter  II,  “Problem 
Definition,”  provides  an  analysis  of  the  true  nature  of  the  tasking  statement  and  the 
problem  statement  that  the  team  derived  from  it.  This  chapter  also  defines  terminology 
essential  to  the  understanding  of  this  system  architecture  as  well  as  the  assumptions  and 
boundaries  to  the  problem  that  are  critical  to  framing  the  proposed  training  system  within 
the  context  of  the  larger  webfires  concept.  Chapter  III,  “Needs  Analysis,”  summarizes  the 
process  to  discover  the  needs  of  the  stakeholders  and  the  specific  issues  that  were  raised 
through  research,  stakeholder  site-visits,  and  interviews. 

The  next  three  chapters  analyze  the  current  training  system  and  how  integration 
plays  a  part,  as  well  as  analyzing  and  comparing  the  current  system  to  the  needs  of  the 
proposed  webfires  training  system  (WFTS).  The  third  chapter  in  this  section  provides  an 
overview  of  the  purpose  and  methodology  of  the  future  training  system.  Chapter  IV, 
“Current  Training  Process,”  details  the  methods  and  process  that  current  naval  personnel 
undergo  to  achieve  individual  qualifications  as  well  as  unit  level  qualifications.  Chapter 
V,  “Gap  Analysis,”  compares  the  current  process  to  the  defined  needs  of  the  future 
system  as  discovered  through  stakeholder  interviews.  This  analysis  presents  several 
major  gaps  that  the  proposed  system  architecture  will  attempt  to  resolve.  Chapter  VI, 
“Concept  of  Operation,”  details  the  general  process  that  personnel  and  units  will  undergo 
in  the  proposed  WFTS. 

Chapters  VII  through  X  capitalize  on  the  identification  of  gaps  and  the  problem 
definition  to  lay  out  a  system-of-systems  design.  Chapter  VII,  “System  Requirements,” 
looks  at  both  the  capabilities  and  requirements  that  a  system  must  possess  in  order  to  fill 
the  gaps  that  are  determined  in  Chapter  V.  Chapter  VIII,  “Functional  Analysis,”  identifies 
the  system  functions,  both  people  and  material,  that  the  system  must  have  to  meet  the 
requirements  identified  in  Chapter  VII. 

Chapter  IX,  “Analysis  of  Alternatives,”  presents  the  process  that  the  team  used  to 

complete  an  analysis  of  alternatives.  This  analysis  enabled  the  team  to  identify  which 
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design  option  best  addresses  the  gaps  identified  in  Chapter  V.  Chapter  X,  “System 
Architecture,”  combines  all  of  the  efforts  of  the  previous  chapters  and  formulates  a 
comprehensive  system  architecture. 

Finally,  this  report  concludes  with  a  Chapter  XI,  “Summary,  Conclusions,  and 
Recommendations.”  The  final  chapter  summarizes  this  report’s  findings,  contains  a 
detailed  list  of  conclusions  along  with  actionable  recommendations,  and  a  list  of 
recommended  topics  for  further  research.  The  various  appendices  at  the  end  of  the  report 
contain  the  official  tasking  statement,  amplifying  information  for  certain  chapters,  and 
Institutional  Review  Board  (IRB)  approved  questions  and  documentation. 

B.  PROJECT  BACKGROUND 

The  capstone  project  officially  started  in  September  2016  during  the  fall  2017 
academic  quarter.  The  team  was  required  to  identify  and  integrate  students  from  the 
National  University  of  Singapore’s  Temasek  Defense  Systems  Institute  (TDSI),  as  well 
as  students  and  faculty  of  relevant  Naval  Postgraduate  School  (NPS)  programs  into  the 
project  to  provide  technical  knowledge  and  insights  and  aid  in  research  and  report 
writing.  The  team  then  had  three  quarters  to  deliver  a  completed  project  report  and  final 
briefing  materials  to  NPS  faculty  advisors  and  the  Pentagon.  The  team  received  official 
tasking  from  the  Office  of  the  Chief  of  Naval  Operations  (OPNAV)  Deputy  Chief  of 
Naval  Operations  for  Warfare  Systems  -  Integration  Division  (N9I). 

C.  PROJECT  TEAM 

NPS  enrolls  and  educates  a  diverse  set  of  military  officers  from  around  the  world 
in  several  graduate  schools  and  degree  programs.  The  Systems  Engineering  Analysis 
(SEA)  team  comes  from  an  interdisciplinary  program  from  both  the  Graduate  School  of 
Engineering  and  Applied  Sciences  (GSEAS)  and  the  Graduate  School  of  Operational  and 
Information  Science  (GSOIS).  The  resident  students  critical  to  the  success  of  this  project, 
as  well  as  their  warfare  backgrounds,  are  listed  in  Table  1. 
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Table  1.  Resident  Team  Members 


Rank  and  Name 

Service 

Warfare  Designator  and  Past  Experience 

LCDR  Daniel  DeCicco 

USN 

Naval  Aviator,  MH-60S 

LT  Matthew  Alvarez 

USN 

Naval  Aviator,  MH-60S/SH-60F/HH-60H 

LT  Benjamin  Arnett 

USN 

Naval  Aviator,  MH-60S 

LT  Michael  Hook 

USN 

Surface  Warfare  Officer,  CRU/DES 

LT  Austin  Thompson 

USN 

Submarine  Warfare  Officer,  SSBN 

LT  Kevin  Weeks 

USN 

Surface  Warfare  Officer,  CRU/DES 

LT  Seng  Yee 

USN 

Information  Professional  Officer,  CRU/DES 

Supplementing  the  core  team  are  students  that  have  completed  at  least  six  months 
of  graduate  education  at  Singapore’s  TDSI.  These  students  are  required  to  contribute  to 
this  project  in  partial  fulfillment  of  their  own  degree  requirements.  Additionally,  these 
individuals  bring  a  wide  variety  of  knowledge  and  experience  to  the  table,  even  as  they 
are  working  in  their  own  academic  disciplines  and  completing  individual  theses.  Their 
specialties  are  in  the  areas  of  operational  research,  computer  science,  mechanical, 
electrical,  and  weapon  systems  engineering,  oceanography,  and  physics.  These  specialists 
and  their  backgrounds  are  listed  in  Table  2. 
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Table  2.  TDSI  Cohort  Members 


Rank  &  Name 

Service 

Background  and  Course  of  Study 

LT  Ryan  Beall 

USN 

Naval  Aviator,  MH-60S  (Systems 

Engineering) 

LT  Preston  Tilus 

USN 

Surface  Warfare  Officer,  CRU/DES 
(Operational  Research) 

LTJG  Clayton  Petty 

USN 

ADM  Frank  Bowman  Scholarship 
(Mechanical  Engineering) 

MAJ  Dor  Kronzilber 

IDF 

Army  Officer  (Operational  Research) 

ME5  Ang  Chin  Beng 

RSAF 

Air  Force  Engineer  (Weapon  Systems 
Engineering) 

ME5  Kang  Wei  Sheng 

SA 

Army  Engineer  (Systems  Engineering) 

ME5  Ang  Pak  Siang 

RSAF 

Air  Force  Engineer  (Communications 
Engineering) 

CPT  Ang  Wee  Kiong 

SA 

Army  Intelligence  Officer  (Systems 
Engineering) 

MAJ  Hoon  Dingyao 

SA 

Signals  Officer  (Computer  Science) 

CPT  Gay  Wee  Choon 

SA 

Armor  Officer  (Operational  Research) 

MAJ  Soh  Yuan  Wei 

SA 

Combat  Engineer  Officer  (Systems 

Engineering) 

Yee  Jian  Hong 

DSTA 

Advanced  System  (Weapon  Systems 
Engineering) 

Ang  Cheng  Hai 

DSTA 

Air  System  (Communications  and  Network 
Engineering) 

Han  Keng  Siew 

DSTA 

Network  Systems  (Systems  Engineering) 

Foo  Yueng  Hao 

DSTA 

Communications  Infrastructure  (Computer 
Science) 

Chin  Hon  Keong 

Civilian 

Defense 

Industry 

Land  Systems  (Weapon  Systems  Engineering) 

See  Hongze 

Marine  Systems  (Systems  Engineering) 

Toh  Ying  Jie 

Electrical  and  Electronic  Systems  (Systems 
Engineering) 

Lai  Wee  Leong 

Electrical  and  Electronic  Systems  (Systems 
Engineering) 

Tan  Choon  Seng 

Aerospace  Systems  (Weapon  Systems 
Engineering) 

The  team  has  been  supported  by  many  faculty  members  through  mentorship  and 
instruction  during  their  graduate  education.  Without  the  support,  superior  knowledge,  and 
practical  experience  of  the  lecturers  and  faculty  advisors,  the  team  would  not  be  able  to 
focus  their  work  into  a  meaningful  discussion  in  the  form  of  this  report.  The  faculty 
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advisors  and  subject  matter  experts  (SMEs)  especially  critical  to  the  success  of  this 
project,  as  well  are  their  respective  departments,  are  listed  in  Table  3. 


Table  3.  Resident  Faculty  Advisors 


Rank  and  Name 

Role 

Experience 

Dr.  Fotis  Papoulias 

Advisor 

NPS  Associate  Professor,  Systems 
Engineering 

Dr.  Michael  Atkinson 

Advisor 

NPS  Professor,  Operational  Research 

CDR  (Ret.)  Bill  Hatch,  USN 

Advisor 

NPS  Professor,  Manpower  Systems 
Analysis 

CAPT  (Ret.)  Jeffrey  Kline, 
USN 

SEA 

Chair 

NPS  Professor  of  Practice,  Operations 
Research 

CAPT  Chuck  Good,  USN 

SME 

COMNAVSURFPAC  Detachment, 
Monterey 

D.  PROJECT  FOUNDATIONS 

The  recommendations  within  this  report  are  based  on  the  foundations  of  the  Chief 
of  Naval  Operations’  (CNO)  vision  statement  titled  A  Design  for  Maritime  Superiority. 
Contained  within  are  various  lines-of-effort  (LOE)  that  contribute  to  this  vision  and  some 
principles  that  enable  them  (Richardson  2016).  Innovation  and  critical  thinking  play 
heavily  into  the  Admiral  Richardson’s  vision  (2016),  and  accordingly,  the  capstone 
process  began  in  earnest  with  participation  in  the  annual  Warfare  Innovation  Continuum 
(WIC)  Workshop  sponsored  by  the  Consortium  for  Robotics  and  Unmanned  Systems 
Education  and  Research  (CRUSER),  held  each  fall  at  NPS. 

1.  The  CNO’s  Design  for  Maritime  Superiority 

The  CNO’s  2016  vision  contains  several  critical  LOEs  that  provide  a  backdrop  for 
the  implementation  of  the  WFTS.  The  maritime  superiority  design  concept,  in  addition  to 
the  proposed  webfires  concept,  draws  a  focus  on  fleet-wide  readiness  to  engage  in  a  naval 
battle  in  all  waters  and  air  spaces.  According  to  the  CNO  (2016),  the  primary  concepts 
for  implementation  focus  on  the  following  six  pinnacles: 
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1.  Maintain  and  modernize  the  undersea  leg  of  the  strategic  deterrent  triad. 

This  is  foundational  to  our  survival  as  a  nation. 

2.  In  partnership  with  the  Marine  Corps,  develop  concepts  and  capabilities 
to  provide  more  options  to  national  leaders,  from  non-conflict  competition 
to  high-end  combat  at  sea.  Operations  short  of  conflict  should  be  designed 
to  contain  and  control  escalation  on  terms  favorable  to  the  U.S.  Combat  at 
sea  must  address  “blue-water”  scenarios  far  from  land  and  power 
projection  ashore  in  a  highly  “informationalized”  and  contested 
environment.  All  scenarios  must  address  the  threat  of  long-range  precision 
strike.  Test  and  refine  concepts  through  focused  wargaming,  modeling, 
and  simulations.  Validate  these  concepts  through  fleet  exercises,  unit 
training,  and  certification. 

3.  Further  advance  and  ingrain  information  warfare.  Expand  the 
Electromagnetic  Maneuver  Warfare  concept  to  encompass  all  of 
information  warfare,  to  include  space  and  cyberspace. 

4.  To  better  meet  today’s  force  demands,  explore  alternative  fleet  designs, 
including  kinetic  and  non-kinetic  payloads  and  both  manned  and 
unmanned  systems.  This  effort  will  include  exploring  new  naval  platforms 
and  formations — again  in  a  highly  “informationalized”  environment — to 
meet  combatant  commander  needs. 

5.  Examine  the  organization  of  United  States  Fleet  Forces  Command, 
Commander  Pacific  Fleet,  and  their  subordinate  commands  to  better 
support  clearly  defining  operational  and  warfighting  demands  and  then  to 
generate  ready  forces  to  meet  those  demands. 

6.  Examine  OPNAV  organization  to  rationalize  our  headquarters  in 
support  of  warfighting  requirements.  Warfare  Innovation  Continuum. 
(Richardson  2016,  6) 

Also  critical  to  the  success  of  the  WFTS  is  the  introduction  and  use  of  high- 
velocity  learning.  This  is  a  primary  tenet  of  the  CNO’s  vision.  In  the  NPS  Update 
newsletter  dated  August  2016,  Kenneth  A.  Stewart  summarizes  the  origin  of  high- 
velocity  learning: 

The  term  high-velocity  learning  was  penned  by  Steven  J.  Spear  in  his 
book,  The  Velocity  Edge.  This  innovative  model  explores  methods  for 
building  a  system  of  “dynamic  discovery”  for  seeing  and  solving  problems 
as  they  occur,  sharing  information  to  help  convert  weaknesses  into 
strengths,  and  developing  leaders  who  are  invested  in  their  subordinates’ 
successes.  (Stewart  2016,  3) 
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It  is  important  to  note  that  high-velocity  learning  is  a  skill  and,  like  any  other 
skill,  it  requires  practice. 

2.  Warfare  Innovation  Continuum  Workshop 

The  annual  WIC  workshop  is  a  themed  and  coordinated  effort  to  leverage  NPS 
cross-campus  educational  and  research  activities  as  well  as  technology  and  defense 
industry  personnel  to  explore  innovative  solutions  and  “apply  emerging  technologies  to 
shape  the  way  we  fight”  (CRUSER  2016).  The  main  thrusts  of  the  CNO’s  vision,  as  well 
as  how  the  foundations  of  systems  engineering  will  contribute  to  its  success,  are 
expanded  upon  in  the  following  paragraphs. 

The  timeline  for  the  annual  WIC  is  displayed  in  Figure  1,  where  the  important 
capstone  deadlines  are  annotated  in  addition  to  some  coursework  and  academic 
milestones.  As  the  graphic  shows,  the  WIC  Workshop  was  held  in  September  2016,  and 
the  capstone  report  is  due  in  lune  2017. 


Source:  CRUSER  (2016). 

Figure  1.  2016  WIC  Timeline  and  Project  Milestones. 
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In  the  fall  of  2016,  a  continuum  focused  on  naval  power  in  the  littorals  and  titled 
Developing  Autonomy  to  Strengthen  Naval  Power  was  held  at  NPS  (CRUSER  2016).  The 
purpose  of  this  conference  was  to  integrate  members  from  a  variety  of  backgrounds  to 
apply  creative-thinking  skills  and  propose  unique  solutions  to  a  theoretical  future  combat 
problem.  The  diverse  personnel  in  attendance  included  warfare-qualified  U.S.  military 
officers  and  civilians  enrolled  in  various  degree  programs  at  NPS,  engineers  from  Silicon 
Valley  and  Department  of  Defense  (DOD)  laboratories,  and  accomplished  members  of 
the  academic  community. 

a.  WIC  Workshop  Focus  Areas 

As  found  on  the  WIC  Sakai  website,  this  group  of  diverse  professionals 
concentrated  their  incorporation  of  ideas  and  technologies  into  three  main  discussion 
areas: 


1.  Littoral  Mesh  Networking  and  Remote  Sensing:  These  concepts  all 
employ  autonomy  to  create  a  mesh  network  of  communications  and 
sensing  nodes  in  a  contested  urban  littoral  environment.  Concepts  in  this 
category  include  Remote  Aerial  Vehicle  Information  Network  (RAVIN), 
“Soccerball”  Small  Distributed  Phased-Array  Jammer,  Civil 
Infrastructure:  Autonomous  Support  for  HA/DR,  Ground  Surx’eillance 
System  Deployable  ISR  Packages,  and  the  Robotic  Self-Healing  Mesh 
Network. 

2.  Innovative  Undersea  Warfare:  These  concepts  leverage  autonomy  to 
clear  and  secure  sea  lanes  and  harbor  approaches  for  landing  and  resupply 
in  a  contested  urban  littoral  environment.  Concepts  in  this  category 
include  HYDRA  Shield  and  Autonomous  Guard. 

3.  Autonomous  Unmanned  Submersible  Missions:  These  concepts 
employ  autonomy  to  leverage  or  disable  all  available  assets  in  a  contested 
urban  littoral  environment.  Concepts  in  this  category  include  USVs  of 
Opportunity  and  “The  Heisman”  Autonomous  Bumper  Boat.  (CRUSER 
2016) 

b.  WIC  Workshop  Results 

The  four-day  effort  culminated  in  presentations  to  military  and  industrial  leaders, 
highlighting  complex,  innovative,  and  synergistic  solutions  to  these  main  topics.  A  final 
For  Official  Use  Only  (FOUO)  report  was  generated  based  on  the  work  and  is  available 
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to  authorized  users.  The  results  of  this  continuum  align  with  the  CNO’s  vision  and  lay  the 
groundwork  for  this  report. 

E.  SYSTEMS  ENGINEERING 

Early  on  in  the  graduate  program,  the  team  learned  several  accepted  definitions  of 
“systems  engineering”  and  unique  tenets  apply  to  the  field.  The  preeminent  governing 
body  of  systems  engineering,  the  International  Council  on  Systems  Engineering 
(INCOSE),  has  published  a  thorough  and  widely  used  definition.  According  to  the 
INCOSE  website: 

Systems  Engineering  is  an  interdisciplinary  approach  and  means  to  enable 
the  realization  of  successful  systems.  It  focuses  on  defining  customer 
needs  and  required  functionality  early  in  the  development  cycle, 
documenting  requirements,  then  proceeding  with  design  synthesis  and 
system  validation  while  considering  the  complete  problem: 

Operations,  Performance,  Testing,  Manufacturing,  Cost  and  Schedule, 
Training  and  Support,  and  Disposal. 

Systems  Engineering  integrates  all  the  disciplines  and  specialty  groups 
into  a  team  effort  forming  a  structured  development  process  that  proceeds 
from  concept  to  production  to  operation.  Systems  Engineering  considers 
both  the  business  and  the  technical  needs  of  all  customers  with  the  goal  of 
providing  a  quality  product  that  meets  the  user  needs.  (INCOSE  2017) 

1.  Process  Models 

It  is  very  important  for  the  project  team  to  review  and  understand  different  types 
of  systems  engineering  process  models  in  order  to  choose  and  apply  an  appropriate  one. 
There  are  three  well-known  systems  engineering  process  models  described  by  Blanchard 
and  Fabrycky’s  Systems  Engineering  and  Analysis  textbook.  From  these  process  models, 
the  team  has  selected  a  systems  engineering  process  model  that  best  supports  the  project. 

a.  Waterfall  Model 

The  first  systems  engineering  process  model  is  the  waterfall  process  model.  The 
waterfall  model  is  a  linear  sequential  model.  According  to  Blanchard  and  Fabrycky,  “this 
model  consists  of  five  to  seven  series  of  steps  or  phases  for  systems  engineering  or 
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software  development  and  each  phase  is  carried  out  to  completion  in  sequence  until  the 
product  is  delivered”  (Blanchard  and  Fabrycky  2011,  36). 

Ideally,  this  is  the  most  efficient  process  model;  however,  in  reality  issues  always 
come  up  during  the  systems  engineering  process.  Based  on  this  model,  problems  are  not 
discovered  until  the  next  phase  is  delayed  or  the  system  is  completed.  As  a  result,  this 
model  lacks  the  flexibility  for  instant  feedback  throughout  the  entire  process. 
Nevertheless,  in  this  project,  the  team  requires  adopting  a  systems  engineering  process 
model  that  provides  flexibility  and  feedback  throughout  that  process  to  develop  the 
desired  system.  The  waterfall  model  is  shown  in  Figure  2. 


Adapted  from  Blanchard  and  Fabrycky  (201 1). 


Figure  2.  Waterfall  Process  Model. 


b.  Spiral  Model 

The  second  systems  engineering  process  model  is  the  spiral  process  model. 
According  to  Blanchard  and  Fabrycky,  “the  spiral  model  is  an  adaptation  of  the  waterfall 
model  and  it  incorporates  feedback  into  the  process.  It  is  iterative  and  proceeds  through 
several  phases  each  time  a  different  type  of  prototype  is  developed”  (Blanchard  and 
Fabrycky  2011,  37). 
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This  model  is  known  to  be  very  time  consuming  and  difficult  to  manage.  Due  to 
the  compressed  nature  of  the  project  tasking,  the  team  requires  a  systems  engineering 
process  model  that  is  less  time  consuming  and  more  manageable  throughout  the  systems 
engineering  process,  and  therefore  the  team  did  not  choose  this  model.  The  spiral  model 
is  shown  in  Figure  3. 


Source:  Boehm  (2000). 


Figure  3.  Spiral  Process  Model. 
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c. 


“Vee”  Model 


The  third  systems  engineering  process  model  is  the  “Vee”  process  model.  The 
“Vee”  model  is  an  extension  of  the  waterfall  model  and  incorporates  feedback  loops 
throughout  the  process.  According  to  Blanchard  and  Fabrycky,  “this  model  starts  with 
user  needs  on  the  upper  left,  proceeds  down  the  left  side  of  the  “Vee”  and  across  at  each 
level,  ending  with  a  user-validated  system  on  the  upper  right”  (Blanchard  and  Fabrycky 
2011,  37).  This  model  is  less  time  consuming  than  the  spiral  model.  Based  on  these 
advantages,  the  “Vee”  model  is  most  suited  for  the  capstone  project.  A  graphic  depiction 
of  the  “Vee”  model  is  shown  in  Figure  4. 


Source:  Clark  (2009). 


Figure  4.  “Vee”  Process  Model. 


2.  Selected  Design  Approach 

The  team  approached  the  training  system  design  with  a  five-step  process  most 
similar  to  the  “Vee”  model.  The  first  step  is  to  clearly  define  the  webfires  concepts  and 
identify  its  boundaries  so  that  its  training  requirements  are  identified.  The  second  step  is 
to  conduct  gap  analysis  on  current  platform-centric  training  and  compare  it  to  webfires 

required  training  in  order  to  leverage  cross-domain  and  cross-platform  technologies.  The 
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third  step  is  to  understand  the  training  needs  and  generate  thorough  training  requirements. 
The  fourth  step  is  to  develop  a  training  system  architecture.  The  fifth  step  is  to  produce  a 
complete  training  system  design  to  support  webfires  concepts.  These  steps  occur 
iteratively  until  the  proposed  system  architecture  satisfies  all  of  the  defined  needs  and 
requirements  of  the  system.  The  selected  system  design  approach  is  shown  in  Figure  5. 


Approach  to  Design 


Lea  rn  i  ng  Centered  Tra  i  n  ing 
Technologies,  Simulators  and 
Optimizing  the  Navy 
Intellectual  Enterprise 


Training  System  for  Tactics 
and  Joint  Operations 


I  Defining  Web-Fire  Concepts  and 
Web-Fire  System  Boundaries 

Concepts 
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Entry  into  the  cycle  occurs  at  “Webfires  Concepts”  and  proceeds  clockwise  around, 
finishing  at  “System  Design.”  However,  each  double  arrow  represents  an  iterative 
process  that  may  require  revisiting  previously  completed  steps. 

Figure  5.  System  Design  Approach 
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II.  PROBLEM  DEFINITION 


According  to  Systems  Engineering  and  Analysis ,  “The  systems  engineering 
process  generally  commences  with  the  identification  of  a  ‘want’  or  ‘desire’  for  something 
based  on  some  ‘real’  deficiency”  (Blanchard  and  Fabrycky  2011,  57).  Often  times,  the 
stakeholder  has  a  want  or  a  desire  to  fix  a  specific  deficiency,  but  may  not  truly 
understand  the  actual  nature  of  the  deficiency.  That  is  why  as  part  of  the  systems 
engineering  process,  stakeholders  must  be  interviewed  to  aid  the  systems  engineers  in 
determining  a  “comprehensive  statement  of  the  problem  [with]  specific  qualitative  and 
quantitative  terms  and  in  enough  detail  to  [define  the]  ‘real’  problem  and  its 
importance”  (57). 

A.  TASKING  STATEMENT  AND  PROBLEM  STATEMENT 

In  October  of  2016,  the  team  received  its  tasking  statement  from  OPNAV  N9I, 
the  government  sponsor  for  the  Systems  Engineering  Analysis  Curriculum  and  the 
primary  stakeholder  for  this  project.  The  official  tasking  statement  is  in  APPENDIX  A. 
After  receiving  the  tasking  statement,  the  team  established  smaller  working  groups  in 
order  to  research,  identify,  and  interview  stakeholders;  make  critical  assumptions;  and 
scope  the  project  to  an  appropriate  level.  Through  this  process,  the  team  was  able  to 
discern  and  analyze  the  underlying  problem  that  this  capstone  project  addresses. 

1.  Tasking  Statement 

Design  a  fleet  system  of  systems  and  concept  of  operations  for  employment  of  a 
cost  effective  training  system  capable  of  preparing  naval  warfighters  to  employ  and 
leverage  the  webfires  concents  and  technologies  in  the  2025-2030  timeframe. 

•  Consider  training  across  warfare  missions  and  specialties. 

•  Conduct  research  to  provide  a  solid  foundation  of  knowledge  requirements 
for  a  webfires  fleet  concept. 

•  Complete  a  gap  analysis  by  comparing  current  fleet  training  with  the 
required  training  to  leverage  cross-domain  and  cross-platform  capabilities 
in  a  warfighting  environment. 
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•  Scan  for  current  examples  of  cross-domain  training  and  current  training 
simulation  from  DOD  and  industry. 

•  Develop  a  system  architecture  addressing  responsible  command,  training 
requirements,  training  and  exercise  venues,  and  training  participants  to  fill 
discovered  gaps  in  meeting  the  knowledge  requirements. 

•  Assess  the  proposed  system  against  the  principles  of  high-velocity 
learning  found  in  the  CNO’s  A  Design  for  Maintaining  Maritime 
Superiority.  (Appendix  A) 

The  italicized  and  underlined  text  of  the  tasking  statement  indicates  the  topics  that 
the  team  focused  and  built  upon.  The  tasking  statement  identified  several  key  aspects  that 
the  team  used  to  conduct  research,  outline  stakeholder  interviews,  and  develop  critical 
assumptions.  The  analysis  of  the  tasking  statement  enabled  the  creation  of  the  actual 
problem  statement  that  gives  direction  and  scope  to  capstone  the  report. 

2.  Problem  Statement 

Through  the  process  just  delineated,  the  team  crafted  the  following  problem 
statement: 

Develop  a  cost-effective  operational  training  system  architecture  for  a  webfires 
concept.  The  system  architecture  will  help  support  training  on  webfires  specific 
evolutions  during  the  basic,  integrated,  and  sustainment  phases  of  the  OFRP.  The 
proposed  training  system  will  enable  CSG/ESG  units  to  successfully  conduct  missions  in 
the  2025-2030  timeframe  by  leveraging  high-velocity  learning  with  current  and  future 
technology. 

This  chapter  also  provides  definitions  of  key  terms:  Cost  Effective ,  Webfires,  and 
High-Velocity  Learning.  These  definitions  support  an  understanding  of  the  terminology 
used  with  respect  to  this  research.  Additionally,  critical  assumptions  and  boundaries  are 
defined  and  discussed  in  order  to  effectively  scope  this  report. 

B.  ASSUMPTIONS 

According  to  The  Thinkers  Guide  to  Engineering  Reasoning,  “Reasoning  can  be 
only  as  sound  as  the  assumptions  on  which  it  is  based”  (Paul,  Niewoehner,  and  Elder 
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2013,  36).  Therefore,  it  is  important  that  engineers  are  clear  about  the  assumptions  they 
make,  that  the  reasons  for  the  assumptions  are  justifiable  given  the  problem,  and  that  the 
assumptions  are  consistent  with  each  other  (2013).  The  assumptions  for  this  report  are 
listed  in  Table  4. 


Table  4.  Assumptions 


Critical  Assumption 

Justification 

Funding 

The  Navy  has  the  intention  of  developing  and  investing 
in  a  webfires  concept,  and  there  will  be  a  need  for 
training  system.  Therefore,  it  is  assumed  that  the  Navy 
will  provide  resources  necessary  to  develop  such  a 
training  system. 

Fully  Developed  Tactics 

The  webfires  concept  is  being  developed  by  multiple 
organizations,  while  the  Warfare  Development  Centers 
(WDCs)  are  working  on  the  technology  and  tactics  that 
are  associated  with  implementing  the  system.  By  the 
year  2025-2030  it  is  assumed  that  the  webfires  concept 
will  have  been  integrated  into  the  fleet  and  that  the 
tactics,  doctrine,  and  procedures  will  exist. 

Current  Training 
Infrastructure 

The  current  training  infrastructure  (schoolhouses, 
simulators,  and  other  training  facilities)  will  support 
the  proposed  WFTS. 

Webfires  Relevancy 

Based  on  the  enemy  threat  and  the  need  for  the  Navy  to 
continually  maintain  and  advance  maritime  superiority, 
webfires  will  aid  in  this  ability  and  will  therefore  still 
be  applicable  to  the  Navy  in  the  future. 

Personnel  Requirements 

Personnel  requirements  to  support  webfires  will  not 
drastically  affect  the  current  Navy  personnel 
requirements.  This  does  not  assume  any  change  in 
future  manpower  requirements. 

Future  Technology 

Evolutionary  technology  and  assumed  technological 
advancements  that  will  occur  between  now  and  the 
years  2025-2030  in  support  of  such  a  training  system 
will  be  produced  using  these  assumed  technologies. 

C.  BOUNDARIES 

Boundaries  are  understood  as  a  defined  limit  to  an  area.  When  applying  this 
definition  to  an  engineering  problem,  boundaries  define  the  limits  of  that  problem.  By 
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making  appropriate  assumptions  and  defining  realistic  boundaries  in  accordance  with  the 
problem  statement,  engineers  are  able  to  scope  a  problem  in  a  way  that  allows  a  realistic 
solution  to  be  drafted.  The  boundaries  for  this  report  are  listed  in  Table  5. 


Table  5.  Boundaries 


Critical  Boundary 

Justification 

Administrative 

Boundaries 

The  team  will  only  look  at  the  Fleet  Forces  Command  level  and 
below  with  respect  to  the  administrative  boundaries  of  the 
system.  Incorporating  higher  administrative  levels,  to  include 
joint  units  and  other  DOD  entities,  would  unnecessarily 
complicate  and  increase  the  scope  of  the  project. 

Operational 

Boundary 

The  team  will  only  look  at  the  Commandant  Command  level 
and  below  with  respect  to  the  operational  boundaries  of  the 
system.  Incorporating  a  higher  national  command  perspective 
would  unnecessarily  increase  the  scope  of  the  project. 

CSG/ESG  Units 

While  the  concept  of  webfires  may  eventually  be  applied  to 
interactions  between  joint  services  and  allied  nations,  for  the 
purpose  of  this  project,  the  scope  will  be  limited  to  units  and 
training  entities  comprised  of  and  integral  to  the  training  of  a 
Carrier  Strike  Group  (CSG)  and/or  Expeditionary  Strike  Group 
(ESG). 

Cyber  Domain 
(non-focus) 

The  webfires  concept  and  Training  System  will  rely  heavily  on 
the  ability  to  share  information  in  cyber  domain.  The  team’s 
focus  is  to  develop  a  training  architecture  that  considers  cyber 
implications  and  information  security;  however,  the  actual 
creation  of  information  safeguards  would  be  outside  the  scope 
of  the  research. 

D.  DEFINITIONS 

The  following  definitions  aid  the  reader  in  the  understanding  of  some  key  terms  in 
this  report. 

1.  Cost  Effective 

Most  definitions  of  cost  effectiveness  revolve  around  some  variation  of  achieving 
the  highest  (or  desired)  quality  for  the  lowest  cost.  Of  course,  the  terms  “desired  value” 
and  “low  cost”  can  have  various  interpretations  across  individuals,  situations,  and 
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applications.  Therefore,  cost  effectiveness  is  an  especially  vague  term  that  can  take  on 
several  different  meanings  depending  on  the  context,  and  it  is  more  specifically  defined 
relative  to  this  project. 

Whatever  method  one  might  use  to  determine  cost  effectiveness,  it  generally 
encompasses  a  multi-faceted  comparison  of  costs  and  performance.  For  example,  cost 
effectiveness  can  be  related  to  the  cost  of  a  project  through  the  total  allowed  budget. 
Using  this  example,  a  solution  must  cost  at  or  below  budget  to  be  considered  cost 
effective.  Another  method  to  determine  cost  effectiveness  is  more  qualitative,  such  as 
how  a  proposed  solution  compares  to  the  current  method  of  doing  business,  or  how  a 
proposed  solution  compares  to  other  alternative  solutions  in  a  solution  space. 

For  this  capstone  project,  a  specific  budget  is  not  officially  available,  and  a  lack  of 
comparisons  to  an  allowed  budget  will  not  be  a  constraint  in  determining  whether  a 
solution  is  cost  effective.  Ideally,  during  the  Analysis-of-Alternatives  phase,  a 
comparison  of  the  costs  and  training  value  for  each  alternative  would  be  plotted  using  the 
Cost  as  Independent  Variable  analysis  technique.  From  this  plot,  the  team  would  be  able 
to  determine  a  cost  efficiency  frontier  to  aid  in  determining  which  solutions  are  the  most 
cost  effective.  Due  to  the  classified  nature  of  the  webfires  system  and  high  end  combat 
systems  simulators,  however,  specific  cost  estimates  were  unattainable  for  this  project. 
Additionally,  other  cost  concerns  should  be  factored  into  high-risk  applications  such  as 
military  operations.  One  particular  cost  concern  is  the  cost  associated  with  failure. 
Inadequacies  in  training  can  have  high  costs  associated  with  them,  particularly  when 
these  training  inadequacies  result  in  a  loss  of  multiple  units  or  lives.  Even  if  inadequate 
training  does  not  lead  to  the  loss  of  units  or  lives,  there  are  other,  less  quantifiable  costs, 
such  as  degraded  mission  accomplishment  or  longer  response  time  in  the  battlespace. 

Due  to  the  complexity  of  the  webfires  technology,  the  inability  to  obtain  cost 
estimates  for  high-end  combat  simulation  systems,  and  the  cost  uncertainties  associated 
with  training  inadequacies,  the  team  has  decided  not  to  provide  specific  monetary  values 
for  cost  effectiveness.  This  does  not  mean  the  need  to  be  cost  effective  was  dismissed 
when  developing  a  training  architecture.  Though  no  quantitative  cost  effectiveness 
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argument  is  presented,  the  goal  of  a  qualitative  cost  effective  training  architecture 
remained  a  focus  throughout  the  project. 

Some  qualitative  cost  effectiveness  can  be  assumed  in  that  it  is  desirable  for  the 
proposed  solution  to  integrate  into  the  existing  training  structure  delineated  in  the 
Optimized  Fleet  Response  Plan  (OFRP).  It  is  desirable  that  the  proposed  solution 
incorporate  existing  training  facilities  and  training  networks  where  feasible,  thereby 
reducing  the  costs  associated  with  building  an  entirely  new  training  network.  Finally,  as 
simulation  technology  improves,  training  facilities  will  be  able  to  simulate  combat 
scenarios  with  greater  fidelity.  In  some  respects,  current  simulations  can  achieve  a  higher 
fidelity  than  is  achievable  in  live  exercises,  particularly  when  simulating  enemy  tactics 
and  weaponry  such  as  missile  profiles. 

There  is  potential  for  large  cost  savings  by  not  sending  an  entire  strike  group 
underway  to  conduct  a  training  exercise  and  instead  conducting  simulated  combat 
scenarios  while  in  port  or  at  a  training  facility.  Nevertheless,  the  ability  to  save  money  by 
training  pier-side  instead  of  underway  does  not  imply  that  all  underway  training  should 
be  replaced  with  in-port  training  for  the  sake  of  cost  effectiveness. 

2.  Webfires 

The  U.S.  Navy  has  traditionally  engaged  enemy  targets  utilizing  a  linear  kill  chain 
process.  This  structure  of  attack,  as  described  by  Admiral  Greenert,  consists  of  four  steps 
and  is  pictured  in  Figure  6: 

1.  Find  the  target. 

2.  Determine  target’s  location,  course,  and  speed. 

3.  Communicate  that  information  coherently  to  the  platform  launching  the 

weapon. 

4.  Launch  the  attack  using  anything  from  a  kinetic  weapon  to 
electromagnetic  systems  to  cyber.  (Greenert  2013) 

This  integrated  attack  profile  has  a  number  of  flaws.  Any  disruption  within  the 
four-step  process  will  render  the  attack  incomplete.  For  this  reason,  the  process  is 
commonly  named  a  kill  chain,  as  any  removed  link  will  break  the  chain.  As  our  efforts 


20 


abroad  work  to  exploit  these  weaknesses  in  adversarial  weapon  systems,  it  would  be 
naive  to  assume  the  enemy  is  not  trying  to  do  the  same  to  our  weapon  systems.  The  kill 
chain  process  now  expands  beyond  the  battlefield  into  the  cyber  domain,  and  requires 
significant  investment  in  the  area  (Hutchins,  Cloppert  and  Amin  2017). 


Adapted  from  Greenert  (2013). 


Figure  6.  Traditional  Kill  Chain  Approach. 


To  combat  the  enemy’s  attempts  to  disrupt  our  kill  chain  process,  and  to  expand 
the  Navy’s  offensive  command  and  control  (C2)  capabilities,  the  DOD  has  invested 
heavily  into  integrated  fires  concepts,  such  as  kill-webs.  As  described  by  Rear  Admiral 
Manazir  in  2016: 

The  Navy  has  many  effective  kill  chains — a  sensor  that  provides  targeting 
data  to  a  platform  that  can  then  launch  a  weapon  against  a  target — in  the 
air,  ground,  surface  and  undersea  domains.  The  service  has  even  made 
progress  netting  together  some  of  these  kill  chains  within  a  single  domain, 
bringing  together  airplanes  that  rely  on  different  communications 
waveforms  and  were  not  built  to  be  interoperable,  such  as  a  recent  effort  to 
bring  the  F-35  Joint  Strike  Fighter  and  its  unique  Multifunction  Advanced 
Data  Link  (MADL)  communications  into  the  Naval  Integrated  Fire 
Control-Counter  Air  (NIFC-CA)  architecture. 

Now,  these  kill  chains  need  to  be  strung  together  to  create  a  cross-domain 
kill  web,  enabling  any  plane  or  any  ship  to  pull  information  from  whatever 
sensor  happens  to  have  relevant  data,  regardless  of  domain. 
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Figure  7  depicts  Admiral  Manazir’s  concept  for  networked  warfare  and  is  used  as 
the  basic  concept  for  webfires  in  this  report.  This  webfires  Operational  View  (OV-1) 
provides  a  standard  DOD  Architecture  Framework  (DoDAF),  or  basic  engineering  view 
of  the  system  of  systems  architecture  behind  kill  webs  and  the  precursor  system  to 
webfires.  Traditionally,  each  unit  would  operate  independently,  only  utilizing  onboard 
sensors  and  weapons.  For  example,  the  F-35  pictured  at  the  top  of  the  figure  would  utilize 
a  kill  chain  that  would  find  the  target  using  onboard  radars  or  cameras.  Next,  the  onboard 
computer  would  calculate  the  onboard  missiles  launch  profile.  The  pilot  would  launch  the 
missile  once  instructed  to  do  so. 


Adapted  from  Manazir  (2016). 
Figure  7.  Networked  Warfare. 


Now  each  step  in  the  engagement  sequence,  utilizing  a  kill  web,  would  include 
additional  sensors  or  weapons  that  give  the  best  situational  awareness  or  tactical  ability  to 
strike  the  target.  For  example,  the  destroyer  shown  in  Figure  7  could  utilize  the  over-the- 
horizon  radar  capability  of  the  F-35  for  targeting  information  and  launch  an  offensive 
weapon  against  a  threat  that  would  otherwise  be  impossible  for  the  destroyer  to  detect. 

One  example  of  kill  webs  currently  under  advanced  development  for  the  carrier 
strike  group  is  the  Naval  Integrated  Fire  Control  -  Counter  Air  (NIFC-CA).  Although  the 
technical  aspects  of  the  program  are  classified,  in  general,  NIFC-CA  provides  a 
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situational  awareness  and  extended-range  cooperative  targeting  capability  currently 
unavailable  to  the  strike  group.  Another  possible  use  of  the  NIFC-CA  concept  would  be 
to  expand  the  scenario  depicted  in  Figure  7,  where  an  airborne  unit  identifies,  tracks,  and 
targets  an  incoming  missile  for  the  surface  ship.  The  surface  ship  then  fires  a  defensive 
weapon  utilizing  the  airborne  unit’s  targeting  information  to  defeat  the  threat.  A  different 
scenario  would  be  to  use  the  airborne  unit’s  targeting  information  to  launch  an  offensive 
weapon  instead.  These  scenarios  are  shown  in  Figure  8. 


NIFC-CA  From  The  Sea 


Adapted  from  Manazir  (2016). 


Figure  8.  NIFC-CA  Scenarios. 


Rear  Admiral  Manazir  has  stated  “every  unit  within  the  carrier  strike  group — in 
the  air,  on  the  surface,  or  under  water — would  be  networked  through  a  series  of  existing 
and  planned  datalinks  so  the  carrier  strike  group  commander  has  as  clear  a  picture  as 
possible  of  the  battle-space”  (Majumdar  and  LaGrone  2014).  Each  unit  within  the  strike 
group  has  a  unique  role  in  a  kill  web.  Each  unit  acts  as  a  communication  stepping  stone 
for  other  units;  this  is  accomplished  through  the  proper  utilization  of  a  series  of 
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waveforms.  The  current  datalinks  associated  with  high-bandwidth  communication  are 
displayed  in  Figure  9. 


TTNT— the  TTNT  is  long-range,  low  latency,  high 
throughput  data-llnk  that  will  link  together  the 
critical  nodes  ot  NIFC-CA.  These  include  the 
E-2D.  carrier.  UCLASS  and  possibly  the  EA-18G 


Link-16— Linkie  Is  the  standard  data-llnk 
used  by  NATO.  The  Super  Hornet  will  be 
communicate  via  this  data-llnk  since  it  does 
not  need  the  data  throughput  levels  of  some 
of  the  other  aircraft  such  as  the  E-2D. 


Link-16/CMN-4 — this  advanced  version  of 
Link-16  is  a  potential  alternative  to  TTNT  on  the 
Growler.  Basically,  it  is  four  Link-16  systems 
running  concurrently 


Advanced  Tactical  Data-llnk— The  F-35C  will 
need  a  long-range,  low  probability  of  intercept, 
jam-resistant  data-link  to  relay  its  targeting  data 
back  to  the  E-20.  Lockheed  Marlin  is  working  on 
the  capability  for  the  jet's  Block  IV  configuration. 


Adapted  from  Majumdar  and  LaGrone  (2014). 
Figure  9.  Webfires  Datalinks. 


3.  High-Velocity  Learning 

To  continue  to  meet  the  commitments  of  the  nation  at  an  affordable  price-point, 
the  U.S.  Navy  must  adjust  its  ability  to  leam  and  train  to  the  evolving  maritime  security 
environment.  It  must  adopt  more  innovative  and  intuitive  learning  models  in  order  to 
maintain  a  fleet  ready  to  operate,  fight,  and  win  decisively.  As  described  in  the  CNO’s 
vision  (Richardson  2016),  to  achieve  high-velocity  learning  the  U.S.  Navy  will: 

Apply  the  best  concepts,  techniques  and  technologies  to  accelerate 
learning  as  individuals,  teams  and  organizations.  Clearly  know  the 
objective  and  the  theoretical  limits  of  performance — set  aspirational  goals. 

Begin  problem  definition  by  studying  history — do  not  relearn  old  lessons. 

Start  by  seeing  what  you  can  accomplish  without  additional  resources. 

During  execution,  conduct  routine  and  rigorous  self-assessment.  Adapt 
processes  to  be  inherently  receptive  to  innovation  and  creativity. 

1.  Implement  individual,  team,  and  organizational  best  practices  to 
inculcate  high-velocity  learning  as  a  matter  of  routine. 

2.  Expand  the  use  of  learning-centered  technologies,  simulators,  online 
gaming,  analytics,  and  other  tools  as  a  means  to  bring  in  creativity, 
operational  agility  and  insight. 
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3.  Optimize  the  Navy  intellectual  enterprise  to  maximize  combat 
effectiveness  and  efficiency.  Reinvigorate  an  assessment  culture  and 
processes. 

4.  Understand  the  lessons  of  history  so  as  not  to  relearn  them.  (2016,  7) 

Traditionally,  the  U.S.  Navy  is  a  highly  structured  institution  with  deep  routed 
learning  and  training  habits.  “Most  organizations  are  hindered  by  a  structural  problem: 
they  manage  their  functions  individually,  not  as  steps  in  a  well-integrated  process.  Each 
function  does  its  job  and  somehow  the  whole  thing  comes  together — except  when  it 
doesn’t”  (Spear  2009,  357). 

High-velocity  learning  allows  for  better  management  of  individual  functions  as 
they  apply  to  the  overall  operation.  Within  the  webfires  concept,  utilizing  a  high-velocity 
learning  approach  can  better  ensure  sailors  receive  relevant  and  accurate  knowledge 
throughout  their  individual  and  integrated  training.  This  approach  not  only  increases  a 
sailor’s  likelihood  of  being  successful,  but  also  increases  the  individual’s  opportunity  to 
learn.  A  model  of  the  high-velocity  learning  process  is  summarized  by  Spear  (2009) 
below  and  illustrated  in  Figure  10. 

Rather  than  letting  each  experience  be  either  a  success  or  a  failure — but  in 
neither  case  improving  anyone’s  chance  of  success  on  the  next  try  [see 
Figure  9-1 ] — every  experience  is  designed  to  increase  the  likelihood  of 
success  on  the  next  try  as  knowledge  and  know-how  accumulate  [see 
Figure  9-2].  (118) 
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Figure  9-1  Succeed  or  fail 
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Figure  9-2  Succeed  or  learn  to  succeed 
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Source:  Spear  (2009). 
Figure  10.  Likelihood  of  Success. 


Technology  continues  to  develop  at  an  exponentially  faster  rate;  the  currently 
outdated  and  rigorously  structured  learning  model  places  sailors  at  a  severe  disadvantage 
in  the  operational  environment.  It  is  vital  to  mission  success  that  equal  importance  is 
applied  toward  both  developing  the  technical  competency  to  perform  various  functions 
and  the  way  that  watch  standers,  watch  teams,  and  technologies  contribute  to  the 
operation  of  which  they  are  a  part. 

Highlighted  in  the  early  parts  of  the  essay  A  Naturalistic  Study  of  Insight,  two 
efforts  that  can  enhance  human  performance  during  high-velocity  learning  include 
reducing  the  number  of  mistakes  and  by  increasing  insights  (Klein  and  Jarosz  2011). 
Many  examples  illustrate  the  bureaucratic  and  systemic  lop-sided  focus  on  the  first  effort 
over  the  second.  According  to  Klein  and  Jarosz,  the  complaint  that  typically  emerges 
from  this  imbalance  centers  on  students’  failure  to  gain  problem-solving  insights  due  to 
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limited  time,  resources,  and  attention  caused  by  the  undue  emphasis  on  reducing  mistakes 

(2011). 


4.  Types  of  Training 

The  Navy,  as  a  whole,  conducts  many  different  types  of  training.  For  the  purpose 
of  this  report,  training  is  divided  into  three  essential  types:  individual,  unit,  and  multi-unit 
training. 


a.  Individual  Training 

Individual  training  is  training  that  the  Navy  provides  officers  and  sailors  to 
prepare  them  to  perform  their  specific  occupational  duties  and  attain  their  initial 
qualifications.  This  type  of  training  focuses  on  the  individual  and  can  consist  of 
classroom  instruction,  simulator  time,  or  other  forms  of  occupational  training. 

b.  Unit  Training 

Unit  training  is  the  type  of  training  that  units  perform  as  a  whole  to  train  their 
watch  teams  and  sailors  to  work  together  to  perform  missions  that  a  unit  would  be 
expected  to  perform.  This  training  focuses  more  on  team  performance  and  less  on 
individuals. 


c.  Multi-Unit  Training 

Multi-unit  training  is  the  type  of  training  that  focuses  on  units  being  able  to 
perform  missions  with  other  units.  The  number  of  units  involved  in  this  training  can 
range  from  as  few  as  two  (such  as  a  surface  ship  conducting  an  anti-submarine  warfare 
mission  with  a  helicopter)  to  a  full-scale  strike-group  exercise  comprised  of  an  air  wing, 
multiple  surface  ships,  submarines,  or  various  combinations  of  such  assets. 
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III.  NEEDS  ANALYSIS 


A.  STAKEHOLDER  ANALYSIS 

Stakeholder  analysis  is  a  tool  to  help  the  systems  engineer  better  understand  the 
problem  at  hand.  Primary  reasons  for  conducting  stakeholder  analysis  include:  to  identify 
the  people  and  organizations  relevant  to  the  problem,  and  to  determine  their  needs,  wants, 
and  desires  with  respect  to  the  project  outcome.  A  secondary  purpose  is  to  start 
identifying  critical  assumptions  and  constraints  on  the  problem.  At  the  conclusion  of  this 
analysis,  the  systems  engineer  should  have  a  better  understanding  of  the  real  problem  at 
hand.  This  analysis  is  derived  in  the  form  of  a  revised  problem  statement. 

The  revised  problem  statement  clearly  outlines  the  true  underlying  needs  of  the 
client.  Solving  the  revised  problem  statement  is  the  objective  that  the  proposed  design 
architecture  strives  to  obtain.  This  is  the  critical  point  on  which  the  rest  of  the  solution  is 
built.  To  develop  a  satisfactory  problem  statement  for  the  client,  the  systems  engineer 
must  conduct  the  stakeholder  analysis  properly.  Failure  to  identify  the  correct  problem  or 
failure  to  identify  the  correct  needs  from  the  stakeholders  could  result  in  delivering  the 
client  a  solution  to  the  wrong  problem  as  well  as  wasted  resources  along  the  way.  The 
typical  steps  involved  in  stakeholder  analysis  are  described  in  the  following  paragraphs. 

(1)  Identify  the  Problem 

An  initial  problem  statement  is  usually  provided  to  the  systems  engineer  by  the 
client.  The  initial  problem  statement  received  from  the  client,  however,  is  often  vague  or 
under-developed.  Often  clients  do  not  know  what  it  is  that  they  really  want  or  need.  This 
can  be  expected  because  clients  do  not  perform  their  own  needs  analysis,  do  not  talk  to 
the  other  stakeholders  involved,  and  often  do  not  know  what  feasible  solutions  exist.  That 
is  why  the  client  seeks  the  expertise  of  someone  familiar  with  these  processes:  the 
systems  engineer.  It  is  up  to  the  engineer  to  identify  and  define  the  root  problem. 
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(2)  Identify  Relevant  Stakeholders 

Once  the  initial  problem  is  identified,  its  definition  will  need  to  be  refined.  While 
the  systems  engineer  may  be  an  expert  in  the  system  design  process,  he  or  she  is  usually 
not  an  expert  in  the  content  area  of  the  specific  problem.  For  this  reason,  individuals  with 
expertise  in  the  subject  matter  related  to  the  problem  are  often  included  as  stakeholders. 

The  name  stakeholder  comes  from  the  vested  interest  or  personal  stake  these 
groups  or  people  have  in  the  problem  or  its  solution.  Stakeholders  are  typically  classified 
into  one  of  several  categories:  clients,  sponsors,  decision  makers,  users,  and  analysts.  It  is 
the  systems  engineer’s  task  to  identify  likely  stakeholders  so  that  they  may  be  contacted 
to  provide  some  additional  insight  into  the  requirements  and  needs  that  the  solution  must 
address. 

(3)  Develop  a  List  of  Questions  or  Desired  Information  and  Conduct  Research 
on  the  Problem 

Stakeholders  do  not  always  know  what  they  want  the  solution  to  be,  or  what 
solutions  are  even  feasible.  It  is  the  task  of  the  systems  engineer  to  research  the  problem 
and  determine  what  additional  information  is  needed  from  the  relevant  stakeholders  to 
scope  the  problem  space  and  generate  an  actionable  requirements  list. 

(4)  Conduct  Interviews 

After  identifying  who  the  stakeholders  are,  and  developing  questions  to  determine 
their  needs,  wants,  and  desires  as  they  pertain  to  the  problem  at  hand,  the  next  major  step 
is  to  collect  information  from  the  stakeholders.  This  is  done  by  contacting  the 
stakeholders  directly  to  receive  their  inputs  into  the  problem  and  what  they  might  like  to 
see  in  a  solution.  This  stakeholder  input  helps  to  identify  the  “gap”  between  the  current 
situation  and  the  desired  situation,  where  the  “gap”  represents  the  true  needs  of  the 
solution. 

(5)  Consolidate  Information  Gained 

Individual  stakeholders  do  not  always  have  the  same  needs  as  other  stakeholders. 
Specifically,  the  end  user  may  have  different  needs  from  the  client  providing  the  initial 
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problem,  or  even  the  sponsor  paying  for  the  solution.  Stakeholder  analysis  provides  a 
method  for  compromise  between  the  needs  of  multiple  stakeholders.  This  is  achieved 
when  the  information  from  all  of  the  stakeholders  is  obtained  and  consolidated  into  one 
needs  statement. 

(6)  Iterate  as  Necessary 

It  is  highly  unlikely  that  all  of  the  required  information  will  be  obtained  in  the 
first  phase  of  stakeholder  research.  It  is  likely  new  questions  will  continue  to  arise 
throughout  the  project.  Stakeholder  analysis  is  conducted  as  an  iterative  process.  As  new 
information  from  the  stakeholders  is  gathered,  this  information  is  then  added  to  the 
requirements  generation  process. 

B.  STAKEHOLDER  IDENTIFICATION 

As  part  of  any  successful  systems  engineering  project,  requirements  must  be 
harvested,  analyzed,  and  subsequently  met  by  the  proposed  system;  the  key  engagement 
must  be  with,  and  for,  the  stakeholders.  In  addition  to  the  primary  stakeholder,  OPNAV 
N9I,  the  team  identified  key  stakeholders  to  interview  within  two  primary  geographical 
areas:  Fallon,  NV,  and  San  Diego,  CA.  During  one  of  NPS’s  thesis  and  research  weeks 
(March  2017),  the  team  conducted  site  visits  to  the  commands  shown  in  Table  6.  The 
commands  identified  represent  the  points-of-view  necessary  for  a  majority  of  the 
stakeholder  requirements. 


Table  6.  Interviewed  Stakeholders 


Command 

Location 

Naval  Aviation  Warfighting 

Development  Center  (NAWDC) 

Fallon,  NV 

Tactical  Training  Group,  Pacific  (TTGP) 

San  Diego,  CA 

Naval  Surface  and  Mine  Warfighting 
Development  Center  (SMWDC) 

San  Diego,  CA 

Expeditionary  Warfare  Training  Group, 
Pacific  (EWTGPAC) 

San  Diego,  CA 

Third  Fleet  (COMTHIRDFLEET) 

San  Diego,  CA 

Commander,  Naval  Surface  Forces 

Pacific  (COMNAVSURFPAC) 

San  Diego,  CA 
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Per  NPS  protocol,  it  is  imperative  that  all  questions  to  stakeholders  first  receive 
approval  by  an  Institutional  Review  Board  (IRB)  to  ensure  the  project  is  the  intended 
focus  and  there  is  no  inadvertent  human  research  without  the  proper  procedures  in  place. 
The  team  generated  a  list  of  stakeholder  questions  and  submitted  them  to  the  IRB  and 
SEA  Chair  prior  to  visiting.  The  questions  were  determined  to  not  contain  human  subject 
research  in  any  form.  A  list  of  the  IRB  approved  questions  and  associated  IRB 
documentation  appear  in  Appendix  E. 

1.  Naval  Air  Warfare  Development  Center 

The  primary  mission  of  NAWDC  is  to  provide  aviation  flight  training,  academic 
instruction,  and  operational  and  intelligence  support  for  all  aviation  platforms  throughout 
the  Navy  (CNIC  2017).  Along  with  development  and  updating  of  Tactics,  Techniques, 
and  Procedures  (TTPs)  for  aviation  mission  areas,  NAWDC  provides  subject  matter 
experts  (SMEs)  to  major  commands  that  support  the  OFRP  training  continuum 
throughout  the  world  (2017). 

The  team  noted  the  following  significant  observations  from  NAWDC: 

•  NAWDC  engages  in  integrated  training  primarily  through  established 
systems  such  as  NIFC-CA.  This  system  has  had  significant  impact  on  the 
operations  on  the  tactical  and  operational  level. 

•  Debriefing  of  training  events  conducted  at  NAWDC  is  accomplished  in 
one  room,  with  all  players  in  a  face-to-face  environment.  This  tends  to 
provide  positive  training,  with  all  assets  able  to  follow  thought  processes 
and  resulting  actions  that  occurred  and  is  facilitated  by  local  SMEs.  The 
environment  especially  allows  for  common  references,  increased  synergy, 
and  creative/unique  perspectives  from  various  platforms.  Improvements 
needed  include  increased  man-machine  interfaces,  better  communication 
systems,  higher  fidelity,  and  inclusion  of  key  warfighters  involved  in 
tactical  decisions. 

•  Intelligence  updates  lag  due  to  lack  of  direct  input  and  resultant  changes  to 
the  TTPs.  This  is  primarily  due  to  security  concerns  and  human  interaction 
required  to  determine  importance  and  effectiveness. 

•  Recorded  data  analysis  lags  behind  the  real-time  tactical  engagements 
resulting  in  unknown  effectiveness.  During  training,  operators  must  use 
estimates  and  models  to  evaluate  performance. 
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•  There  is  a  significant  effort  to  integrate  real  and  simulated  world,  such  as 
with  Aegis  Air  Defense  with  aircraft,  but  there  is  a  concern  with  security 
and  data  integrity. 

•  There  is  currently  no  training  timeline  that  unifies  the  phases  of  the  OFRP 
across  multiple  domains  nor  an  established  command  responsibility  for 
integrated  training  requirements. 

•  Geographically,  Fallon,  NV,  is  secluded  from  the  major  fleet 
concentrations,  and  only  a  limited  number  of  personnel  are  currently 
available  to  be  sent  from  commands  for  extended  periods  of  integrated 
training. 

2.  Tactical  Training  Group,  Pacific 

The  Tactical  Training  Group,  Pacific  (TTGP),  along  with  its  East-coast 
counterpart,  Tactical  Training  Group,  Atlantic  (TTGL),  provides  tactical  training  in 
support  of  the  OFRP  training,  specifically  for  and  within  the  numbered  fleets  (U.S.  Navy 
2017b).  They  establish  and  present  curricula,  interactive  simulations,  and  innovative 
feedback  for  customers  (2017b).  They  coordinate  with  Commander,  Carrier  Strike  Group 
Fifteen  (CSG-15)  for  underway  training. 

The  team  noted  the  following  significant  observations  from  TTGP: 

•  Live  Virtual  Constructive  (LVC)  training  has  many  different 
interpretations.  There  is  little  standardization  for  what  constitutes  an  LVC 
training  event  within  tactical  syllabi;  scenarios  take  up  to  a  full  year  to 
develop. 

•  Weapons  and  Tactics  Instructors  (WTI)  as  seen  in  the  aviation  community 
has  become  a  “best-practice”  model  that  surface  vessels  are  implementing. 

•  Networks  such  as  the  Navy  Continuous  Training  Environment  and  Joint 
Semi-Automatic  Lorces  (JSAL)  provide  more  information  and  quicker 
interaction  for  warfighters  to  recognize  enemy/friendly  forces  and  engage 
more  effectively,  but  are  currently  platform  limited  by  the  high  cost  of 
implementation  at  a  tactical  level.  Red  force  players  are  currently  trained 
personnel,  with  no  AI  component. 

•  Lleet  Synthetic  Training  (LST)  requires  robust  communication  networks 
and  bandwidth  and  currently  is  limited  to  CONUS  locations. 

•  Commands  interested  in  TTGP  training  lack  resources  and  people  to  send 
temporarily  for  on-site  training,  and  they  currently  are  limited  in 
connecting  trainers  at  tactical  locations. 
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3.  Surface  and  Mine  Warfare  Development  Center 

The  Surface  and  Mine  Warfare  Development  Center  (SMWDC)  concentrates  on 
the  surface  warfare  community’s  tactical  training  in  six  core  areas,  including  Amphibious 
Warfare,  Air  Warfare,  Ballistic  Missile  Defense  Mine  Warfare,  Missions  of  State,  and 
Surf  ace/ Anti- submarine  Warfare  (SMWDC  2017).  It  supports  training  individuals  in  the 
OFRP  by  developing,  improving,  and  integrating  surface  warfare  doctrine. 

The  team  noted  the  following  significant  observations  from  SMWDC: 

•  Surface  community  is  currently  attempting  standardization  through  the  use 
of  the  Surface  Warfare  Combat  Training  Continuum  and  Surface  Warfare 
Advanced  Tactical  Training  programs. 

•  Adaptation  to  other  communities’  best  practices  has  worked  and  is 
currently  underway  in  the  surface  community  to  establish  a  cadre  of 
recognized  tactical  SMEs  for  standardized  warfare  training. 

4.  Expeditionary  Warfare  Training  Group 

The  Expeditionary  Warfare  Training  Group  (EWTG)  conducts  mostly  classroom¬ 
centric  training  and  instruction  to  support  amphibious  expeditionary  warfare  operations 
that  support  the  U.S.  Navy’s  mission  of  projection  of  power  from  the  sea.  In  addition  to 
construction  and  modifications  of  TTPs,  EWTG  employs  SMEs  in  the  realm  of  modeling 
and  simulation  providing  realistic  synthetic  training  (U.S.  Navy  2017a). 

The  team  noted  the  following  significant  observations  from  EWTG: 

•  Differing  infrastructure  and  communication  networks,  especially  between 
the  United  States  Marine  Corps  (USMC)  and  USN  units,  complicates 
coordination  between  existing  systems.  For  example,  this  has  been  seen  in 
Marine  Air-Ground  Task  Force  Tactical  Warfare  Simulation  (MTWS)  and 
JSAF. 

•  Significant  resources  are  lacking,  especially  for  personnel  considering 
career  timing  and  availability  for  onsite  training  (for  both  student  and 
instructor  roles).  Infrastructure  and  funding  does  not  exist  for  the 
establishment  of  simulators  to  be  placed  with  all  units  that  could  benefit 
from  them. 

•  The  acquisition  process  does  not  integrate  with  other  projects  that  are 
either  already  established  or  in  the  process  of  being  developed. 
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•  Senior  leadership  misinterprets  the  ability  to  integrate  current  commercial 
programs  into  military  training,  as  computer  technology  and  infrastructure 
in  military  systems  are  severely  lacking  the  resources  to  do  so;  there  is  a 
search  for  solutions  that  lack  requirements. 

•  Integration  between  USN  and  USMC  forces  has  suffered  due  to  lack  of 
USN  personnel  billeted  to  the  command. 

5.  Commander,  U.S.  Third  Fleet 

While  one  of  five  numbered  fleets,  Commander,  U.S.  Third  Fleet 
(COMTHIRDFLT)  is  responsible  for  maintenance,  operations,  and  training  of  the  Pacific 
Fleet  and  seaward  approaches  to  the  western  United  States  (Global  Security  2017b). 
Additionally,  as  a  Joint  Task  Force  commander,  COMTHIRDFLT  is  directly  affected  by 
and  responsible  for  integrated  tactical  training  in  conjunction  with  each  subordinate 
command’s  OFRP  cycle  (2017b). 

The  team  noted  the  following  significant  observations  from  COMTHIRDFLT: 

•  Management  of  individual  projected  rotation  date  either  coming  or  leaving 
the  command  is  essential  for  assuring  readiness  or  maintaining  qualified 
warfighters. 

•  NEC  codes  do  not  allow  for  retraining  on  new  and  improved  technologies, 
requiring  more  on-the-job  training,  less  effective  learning,  and  an 
imbalance  of  practical  knowledge  within  and  between  watch  teams. 

•  NIFC-CA  is  operational  only  in  a  Live  environment  and  networks  such  as 
Baseline  9  do  not  integrate  in  FST  environments.  Significant  Information 
Assurance  (IA)  problems  exist  between  broadcasted  and  implemented 
tactics  and  established  networks. 

•  Costs  to  send  vessels  underway  to  train  are  prohibitive.  There  would  be 
significant  cost  savings  in  establishing  quality  underway  training  without 
leaving  the  pier. 

•  Objectives  for  training  are  needed,  no  matter  what  phase  of  the  OFRP  is 
being  executed. 

6.  Commander,  Naval  Surface  Force,  U.S.  Pacific  Fleet 

Commander,  Naval  Surface  Force,  U.S.  Pacific  Fleet  (COMNAVSURFPAC)  is 
the  primary  entity  ensuring  that  surface  forces  operating  in  the  Pacific  and  Indian  Oceans 
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have  completed  all  training,  maintenance,  and  manning  requirements  to  operate  in  joint 
and  cooperative  efforts  to  support  the  Navy’s  global  missions  (Global  Security  2017a). 
Additionally,  within  the  command’s  hierarchy  is  the  Distributed  Lethality  Task 
Force — the  U.S.  Navy’s  concept  of  increasing  offensive  capabilities  of  ships  while 
spreading  the  units’  formation  in  a  synergistic  fashion  (Rowden,  Gumataotao  and  Fanta 
2015). 

The  team  noted  the  following  significant  observations  from 
COMNAVSURFPAC: 

•  Current  communication  networks  are  not  real  time  and  require  specific 
encoding/decoding  that  is  not  compatible  with  budding  technologies  and 
threats.  This  results  in  an  integration  and  interoperability  problem. 

•  As  newer  technology  solves  these  issues  or  webfires  concepts  advance,  a 
central  training  network/facility  will  provide  benefits. 

•  A  recognized  lack  of  in-person  debrief  from  multiple  platforms  is 
acknowledged.  There  is  a  need  to  adopt  SMWDC’s  Plan,  Brief,  Execute, 
Debrief  (PBED)  cycle  for  all  integrated  training  evolutions. 

•  Significant  procurement  and  acquisition  problems  result  in  integration 
concerns. 

•  It  is  not  necessary  to  reinvent  what  actually  exists;  foreign  navies  have 
figured  out  certain  tools  to  facilitate  the  PBED  process. 

•  Tactical  integration  is  not  being  addressed  above  the  Type  Commander 
(TYCOM)  level,  but  remains  a  requirement. 


36 


IV.  CURRENT  TRAINING  PROCESS 


Training  sailors  and  Marines  to  perform  tasks  in  support  of  CSG  or  ESG  missions 
is  a  complex  assignment.  Considerable  repetition  is  needed  for  personnel  to  reach  the 
required  individual  training  level  for  combat  effectiveness  and  to  support  the  unit’s 
missions.  Additionally,  considerable  time  must  be  set  aside  for  entire  training  units  to 
work  with  other  units  that  support  larger  integrated  and  complex  operations.  To  address 
the  demands  placed  upon  the  force,  the  Navy  has  created  a  revised  OFRP,  which  provides 
“continuous  availability  of  manned,  maintained,  equipped,  and  trained  Navy  forces 
capable  of  surging  forward  on  short  notice  while  also  maintaining  long-term 
sustainability  of  the  force”  (Howard  2014).  This  chapter  discusses  how  the  Navy 
currently  trains  individuals,  in  addition  to  how  the  Navy  trains  and  manages  the  Fleet  in 
order  to  provide  a  “flexible  force  to  respond  to  combatant  commander  [needs]”  (Howard 
2014). 

A.  INDIVIDUAL  TRAINING 

The  following  sections  detail  how  individual  sailors  and  officers  are  trained  to 
operate  and  maintain  combat  systems  in  each  community.  For  the  purpose  of  this  section, 
only  personnel  with  responsibilities  that  relate  to  a  submarine,  aircraft,  or  ship’s  combat 
systems  are  examined. 

Regardless  of  the  warfare  area  or  community,  officer  training  focuses  on  the  skills 
and  knowledge  that  officers  must  have,  whereas  enlisted  training  focuses  on  the  skills  and 
knowledge  that  sailors  within  various  ratings  must  possess,  and  combined  training 
focuses  on  watch  team  training. 

1.  Undersea  Warfare  Domain 

Naval  officers  who  volunteer  for  the  Submarine  Force  must  go  through  the 
Nuclear  Power  Training  Course  and  the  Submarine  Officer  Basic  Course  prior  to  arrival 
at  their  first  submarine  command.  Nuclear  power  training  focuses  on  the  skills  that  an 
officer  must  possess  in  order  to  maintain  and  operate  the  nuclear  reactor  onboard 
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submarines.  The  Submarine  Officer  Basic  Course  focuses  on  the  knowledge  and 
leadership  skills  that  an  officer  must  possess  for  basic  submarine  navigation,  contact 
management,  and  warfare  tactics. 

Once  officers  complete  both  training  courses,  they  are  sent  to  their  first  command. 
While  stationed  there,  officers  must  go  through  a  warfare  qualification  process.  This 
qualification  process  ends  with  being  qualified  in  three  positions:  Surface  Officer  of  the 
Deck,  Submerged  Officer  of  the  Deck,  and  Qualified  Submarines,  or  “earning  the 
dolphins.”  During  this  qualification  process,  officers  must  demonstrate  the  ability  to 
conduct  contact  management,  submarine  navigation,  and  warfare  tactics  in  a  real  world 
environment.  After  an  officer  has  completed  the  initial  sea  tour  he  or  she  must  go  to  the 
Submarine  Officer  Advanced  Course  prior  to  returning  to  the  fleet.  This  course  expands 
the  knowledge  and  skills  that  an  officer  learned  during  that  first  sea  tour.  During  this 
phase  of  training  there  is  a  larger  focus  on  warfare  skills  and  tactics. 

Following  boot  camp,  enlisted  sailors  are  sent  to  Groton,  CT,  for  Basic  Submarine 
School  where  they  leam  basic  damage-control  and  firefighting  skills.  Once  they  have 
completed  Basic  Submarine  School  sailors  are  assigned  their  rate.  For  the  purpose  of  this 
report,  it  is  one  of  the  combat  systems  rates,  such  as  Sonar  or  Fire  Control  Technician. 
Both  types  of  technicians  are  responsible  for  operating  and  maintaining  the  equipment 
that  is  associated  with  submarine  weapons  systems.  Once  they  have  been  selected  for 
their  rate,  these  sailors  then  leam  the  basic  skills  and  knowledge  necessary  to  operate  and 
maintain  a  submarine’s  weapons  systems. 

Once  these  sailors  have  completed  their  initial  training  they  are  sent  to  their  first 
sea  command.  While  at  their  first  command,  these  sailors  go  through  a  qualification 
process  that  allows  them  to  learn,  in  an  operational  environment,  the  skills  required  for 
them  to  operate  the  weapon  systems. 

Officers  and  enlisted  sailors  must  be  evaluated  routinely  to  ensure  that  they  are 
maintaining  the  necessary  skills  and  knowledge  to  operate  the  submarine  effectively.  This 
currency  is  maintained  through  the  use  of  proficiency  training,  examinations,  and  watch 
evaluations  conducted  by  superiors. 
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Both  the  officer  and  enlisted  training  pipelines  teach  sailors  the  basic  knowledge 
and  skills  necessary  to  employ  a  submarine  in  a  tactical  environment.  These  pipelines  do 
not  focus  on  combined  team  or  multi-unit  training.  Each  submarine  has  multiple  watch 
teams  composed  of  officers  and  enlisted  sailors  who  must  work  together  as  a  team  to 
tactically  employ  the  ship.  To  train  these  watch  teams,  units  use  a  variety  of  techniques 
and  equipment.  These  include  walk-throughs,  training  simulator  time,  simulated  threats 
using  onboard  systems,  and  practice  scenarios  at  sea. 

Type  commanders  routinely  use  Tactical  Readiness  Examination  Teams  to 
evaluate  a  ship’s  training  level.  More  specifically,  these  teams  evaluate  the  ability  of  a 
submarine  to  conduct  combat  operations.  Additionally,  submarines  frequently  train  with 
Tactical  Readiness  Examination  personnel  aboard  in  order  to  evaluate  the  crew  and 
provide  recommendations  in  areas  where  they  need  improvement. 

2.  Air  Warfare  Domain 

The  naval  aviation  career  path  is  only  offered  to  commissioned  officers  and 
provides  an  opportunity  to  learn  to  fly  while  gaining  the  relevant  knowledge  required  to 
operate  military  aircraft  in  combat  operations.  This  training  is  not  envisioned  to  include 
enlisted  air  warfare  rates.  A  commissioned  officer  begins  the  path  to  becoming  a  naval 
aviator  in  Pensacola,  FL,  where  Student  Naval  Aviators  (SNA)  enroll  in  introductory 
flight  screening  (IFS).  IFS  introduces  the  SNAs  to  a  civilian  flight  program  where  they 
learn  the  basics  of  flying.  Each  student  is  afforded  25  hours  of  single-engine  flight  time 
with  a  minimum  of  two  solo  flights  (without  an  instructor)  in  a  civilian  trainer  aircraft. 
After  successfully  completing  the  requisite  flight  hours  and  a  Federal  Aviation  Authority 
private-pilot  knowledge  test,  the  SNA  transitions  to  Aviation  Preflight  Indoctrination, 
also  located  in  Pensacola. 

Aviation  Preflight  Indoctrination  consists  of  six  weeks  of  classroom  instruction 
focused  on  aerodynamics,  aircraft  systems,  meteorology,  air  navigation,  and  flight  rules 
and  regulations.  After  the  classroom  portion,  SNAs  are  provided  two  weeks  of  practical 
training  that  include  land  survival,  first-aid,  physiology,  and  water  survival  topics. 
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Shortly  after  completing  Aviation  Preflight  Indoctrination,  SNAs  are  enrolled  in 
primary  flight  training.  SNAs  will  learn  to  fly  the  Navy’s  Beechcraft  T-6  Texan  II  at 
either  Naval  Air  Station  (NAS)  Whiting  Field,  FL,  or  NAS  Corpus  Christi,  TX. 

Primary  flight  training  reinforces  basic  flight  skills  learned  at  IFS  while  applying 
additional  rigorous  military  flight  standards.  Ground  school  is  offered  before  any  student 
steps  into  the  T-6  Texan  II.  Basic  knowledge,  including  knowledge  of  aircraft  systems, 
local  flight  rules,  and  emergency  procedures,  are  taught  and  tested.  Next,  the  Contact 
phase  introduces  the  SNAs  to  their  first  of  many  military  training  flights.  The  basics  of 
takeoffs,  landings,  stalls,  and  spins  are  introduced  and  practiced.  The  remainder  of  flight 
time  is  split  among  the  basic  instrument  phase,  aerobatics  phase,  formation  phase,  radio 
instrument  navigation  phase,  night  flight  phase,  and  visual  navigation. 

After  successfully  completing  primary  flight  training,  an  SNA  graduate  will  select 
from  a  number  of  flight  platforms,  such  as  strike  aircraft,  E-2/C-2,  E-6B  mercury, 
maritime  patrol,  or  helicopters.  Each  platform  consists  of  a  platform- specific  flight 
syllabus  performed  during  advanced  flight  training. 

Strike  platform  is  designed  to  train  future  Navy  FA- 18  C/D,  FA-18E/F,  EA-18G 
Growler,  and  F-35C  Lightning  II  pilots.  The  students  will  fly  the  T-45C  and  gain  further 
experience  with  basic  flight  skills  and  additional  air  combat  maneuvering  (ACM),  low- 
level  navigation,  tactical  formation  flying  (TACFORM),  and  carrier  qualifications  (CQ). 

E-2/C-2  platform  is  designed  to  provide  future  E-2/C-2  pilots  dual  engine 
experience  not  obtained  in  primary  flight  training.  The  aircraft  utilized  is  a  military 
variant  of  the  Beechcraft  King  Air  (T-44) 

Rotary-wing  platform  is  designed  to  take  a  newly  minted  fixed-wing  pilot  and 
impart  the  fine  art  of  rotary-wing  flight.  A  classically  trained  helicopter  pilot  teaches 
these  skills  to  students  flying  the  mighty  TH-57  Sea  Ranger.  The  SNA  will  learn  the 
unique  skills  required  to  fly  a  helicopter  within  a  relatively  short  100  hours  of  flight  time. 
A  few  of  the  training  phases  include  helicopter  familiarization,  tactics,  low-level 
navigation,  formation  flight,  night  flight,  and  search  and  rescue. 
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After  completing  one  of  the  advanced  flight  training  curricula,  the  SNA  will 
graduate  to  become  a  Naval  Aviator,  earning  his  or  her  Navy  “Wings  of  Gold.”  Naval 
aviators  will  transition  to  Fleet  Replacement  Squadrons  where  the  skills  and  tactics 
required  to  operate  fleet  aircraft  are  learned. 

3.  Surface  Warfare  Domain 

Currently  the  surface  force  primarily  trains  its  officers  via  a  combination  of 
schoolhouses  and  at-sea  exercises,  with  simulator  experience  as  a  rare  occurrence.  Prior 
to  arriving  to  their  first  ship,  a  surface  warfare  officer  (SWO)  receives  some  introductory 
classroom  training  on  ship  systems  and  duties,  but  there  is  little  to  no  focus  on  combat  or 
tactics  at  this  early  stage.  After  completion  of  the  first  division  officer  tour  at  sea,  a  SWO 
is  for  more  advanced  schoolhouse  training  called  Advanced  Ship  handling  and  Tactics, 
but  ironically,  there  is  little  combat  or  tactical  training  involved  in  this  schoolhouse 
training.  At  both  introductory  and  Advanced  Ship  Handling  and  Tactics  training, 
simulators  are  used  to  help  train  the  junior  SWOs,  but  these  simulators  predominantly 
focus  on  ship  handling  skills  and  bridge  watch- standing  coordination.  If  a  SWO  is 
fortunate  enough  to  receive  a  billet  into  a  combat  watch-standing  position  for  his  or  her 
second  division  officer  tour,  the  SWO  will  likely  go  to  a  specialized  school.  There  SWOs 
receive  specific  training  for  the  watch  station  they  are  expected  to  qualify  for  and  fill  on 
the  ship.  At  these  schools,  the  training  will  finally  focus  on  learning  tactics.  This  is  taught 
using  a  combination  of  classroom  education  and  tactical  simulations  of  combat  scenarios. 

The  next  major  milestone  of  a  SWO  is  the  department  head  (DH)  tour.  Here  every 
SWO  takes  tactical  responsibility  while  standing  watches  as  a  Tactical  Action  Officer 
(TAO)  in  charge  of  the  ship’s  Combat  Information  Center  (CIC).  In  preparation  for  this, 
the  future  DH  receives  extensive  training  and  simulations.  Once  onboard  the  ship,  they 
receive  more  realistic  training  through  underway  exercises  at  sea. 

A  similar  training  pipeline  takes  place  for  prospective  commanding  officers 
before  they  arrive  at  their  next  at-sea  command.  These  senior  SWOs  will  attend  various 
schools  to  acquire  the  training  necessary  for  commanding  a  ship,  including  a  tactical 
simulator  experience. 
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The  process  for  enlisted  combat  watch  stations  is  similar,  with  the  exception  of 
longer  timelines  at  initial  schools  in  order  to  learn  their  rates,  and  longer  tours  on  any 
particular  ship.  The  bulk  of  the  training  still  takes  place  with  classroom  education  at 
schoolhouses  and  real  world  exercises  while  underway  at  sea.  Simulators  are 
predominantly  used  only  while  pier-side. 

One  element  largely  lacking  from  the  current  SWO  training  and  enlisted  pipelines 
is  widespread  use  of  tactical  simulators,  except  for  when  conducted  at  various  shore 
facilities  prior  to  these  personnel  reporting  to  their  next  at-sea  command. 

B.  OPTIMIZED  FLEET  RESPONSE  PLAN 

The  focus  of  the  OFRP  is  to  “maintain,  train,  deploy,  and  sustain  readiness  when 
at  home  ...  and  yet  to  optimize  that  cycle,  the  Navy  must  align  numerous  ‘subordinate 
processes’  and  balance  goals  of  various  naval  communities,  requiring  a  cross-community 
collaboration”  (Eckstein  2016).  By  implementing  this  process,  the  fleet  will  “ultimately 
be  better  prepared  to  meet  combatant  commander  needs  without  straining  the  ships, 
planes,  and  sailors”  (Eckstein  2016).  The  OFRP  cycle  consists  of  five  phases: 

1.  Maintenance 

2.  Basic 

3.  Integrated 

4.  Advanced 

5.  Sustainment 

These  phases  help  focus  the  Navy’s  activities  and  resources  with  the  following 
lines  of  effort:  “fleet  response  plan  length,  command  and  control  (C2)  alignment, 
manning  and  individual  training,  maintenance  and  modernization,  logistics,  Military 
Sealift  Command  (MSC)  support,  inspections,  unit  and  advanced  training,  and 
operational  and  tactical  headquarters  training”  (Howard  2014,  2). 

The  following  list  is  an  excerpt  from  Admiral  Howard’s  OPNAVINST  3000. 15A. 
By  focusing  the  Navy’s  resources  and  activities  on  these  lines  of  effort,  the  OFRP  will 
help  generate  the  following: 
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Predictable  force  generation  cycles. 


OFRP  cycle  length  that  supports  maintenance  and  training  while 
maximizing  employability. 

Consistent  chain  of  command  throughout  OFRP. 

Right  Sailor,  right  training,  right  time,  in  a  sea-centric  Navy. 

Continue  rotational  crewing  and  required  manning  at  the  beginning  of  the 
basic  phase. 

Stable  and  predictable  maintenance  plan. 

Modernization  that  supports  warfighting  integration  and  interoperability. 

Parts,  ordnance,  and  other  transportation  to  support  training  and 
operations. 

Fully  capable  and  modernized  MSC  ships  available  to  support  fleet 
combat  and  peacetime  requirements. 

Consolidated  and  streamlined  inspections,  certifications,  assessment,  and 
visits. 

Forces  trained  to  a  single  high-end,  near  peer  standard. 

Tactical  headquarters  organization,  capability,  and  capacity  aligned  with 
standardized  maritime  operations  centers.  (Howard  2014) 


1.  OFRP  Cycle 

The  OFRP  cycle  is  a  36-month  cycle  that  begins  in  the  maintenance  phase.  The 
maintenance  phase  is  seven  months  long,  followed  by  the  basic  and  integrated,  or 
advanced  phase  of  seven  months,  and  the  sustainment  and  deployment  phase  of  22 
months.  Each  phase  is  discussed  in  detail.  The  OFRP  is  illustrated  graphically  in 
Figure  11. 
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•  Retains  ECP  framework  /  capacity  with  reduced  global  Ao  (—2.0) 

-  36  month  FRP 

-  Single  8-month  deployment 

-  Starts  with  HST  CSG  in  Nov  2014 
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Readiness  level  contingent  upon  funding 

Adapted  from  Gortney  (2014). 
Figure  11.  OFRP  Cycle. 


a.  Maintenance  Phase 

Typically,  the  maintenance  phase  is  a  24-week  availability  with  a  4-week  post¬ 
availability  shakedown,  but  it  can  be  as  long  as  16  months  (Howard  2014).  As  delineated 
in  Admiral  Howard’s  OFRP,  this  phase  focuses  on  major  shipyard  and  depot-level 
repairs,  upgrades,  force  reconstitution,  and  platform  modernization.  While  performing 
maintenance,  units  must  still  focus  on  individual  and  team  training  in  order  to  maintain  a 
solid  foundation  of  readiness  (2014). 

b.  Basic  Phase 

The  Basic  Phase  starts  directly  after  a  unit  leaves  the  maintenance  phase  and 
typically  lasts  6  months,  though  it  can  vary  depending  on  the  type  of  unit.  According  to 
the  OPNAVINST  3000. 15 A: 

The  basic  phase  focuses  on  development  of  unit  core  capabilities  and 
skills  through  the  completion  of  basic-level  inspections,  certifications, 
assessments  and  visits  and  training  requirements  as  well  as  achieving 
required  levels  of  personnel,  equipment,  supply,  and  ordnance  readiness. 

Units  and  staffs  that  have  completed  the  basic  phase  are  ready  for  more 
complex  integrated  or  advanced  training  events,  or  appropriate  tasking 
[such  as  homeland  security  or  humanitarian  assistance  and  disaster  relief 
operations].  (Howard  2014) 

Basic  phase  training  focuses  on  a  unit  developing  its  core  mission  sets  in 
preparation  to  move  on  to  more  advanced  training  that  will  require  it  to  work  with  other 
units  in  an  integrated  environment  such  as  within  a  CSG,  ESG,  air  wing,  or  Surface 
Action  Group. 
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c.  Integrated  Phase 


“The  purpose  of  integrated  phase  training  is  to  synthesize  individual  units  and 
staffs  into  aggregated,  coordinated  strike  groups  (or  other  combined-arms  forces)  in  a 
challenging,  multi-dimensional  threat,  realistic  warfare  environment”  (Howard  2014). 
During  this  phase,  units  are  given  time  to  complete  required  inspections,  certifications, 
and  multi-unit  training  (both  in  port  and  out  to  sea)  against  high-end  near-peer  threat 
conditions  (Howard  2014).  Upon  completion  of  this  phase  units  will  be  certified  to 
deploy  and  qualified  to  perform  the  following  missions  and  capabilities  at  a  minimum: 

Proficiency  in  intelligence,  surveillance,  and  reconnaissance,  C2,  air 
operations,  maritime  operations,  information  operations,  power  projection, 
ballistic  missile  defense,  peacetime  presence,  amphibious  operations, 
special  operations  forces  support,  combat  search  and  rescue,  mine  warfare, 
sustainment  and  stability  operations,  and  antiterrorism  and  force 
protection.  (Howard  2014,  5) 

d.  Advanced  Phase 

The  advanced  phase  is  only  for  independent  deploying  forces  that  are  not  part  of  a 
CSG  or  ESG  (2014).  Like  the  integrated  phase,  this  phase  gives  time  to  units  to  perform 
training,  certification,  and  inspections.  If  these  units  are  required  to  eventually  aggregate 
into  a  CSG  or  ESG  this  phase  can  also  provide  integrated  training,  as  necessary,  as 
previously  described.  Once  complete  with  this  phase  a  unit  will  be  certified  to  deploy 
(2014). 


e.  Sustainment  Phase 

The  sustainment  phase  begins  when  a  unit  has  completed  basic  or  integrated 
training  and  ends  when  the  unit  returns  to  the  maintenance  phase  (2014).  During  this 
phase,  a  unit  can  be  deployed  as  a  unit,  multi-unit,  or  ESG/CSG  in  support  of  a 
combatant  commander.  During  this  phase,  training  aims  to  maintain  a  unit’s  proficiency 
and  readiness  to  deploy  (2014). 
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2.  Navy’s  OFRP  Organization 

As  discussed  earlier,  the  focus  of  the  proposed  WFTS  is  to  develop  a  system  that 
helps  support  basic,  integrated,  and  sustainment  training.  To  understand  how  the  WFTS 
can  do  this,  we  need  an  understanding  of  the  organization  that  supports  these  three 
phases.  The  following  section  examines  the  organizations  (people,  groups,  units),  the 
activities  (tasks)  they  perform,  and  the  operational  items  (information)  that  are  passed 
between  them. 


a.  Figure  Guidance 

In  Figures  12  through  15,  parallel  lines  represent  the  organizations  involved  in 
each  phase  of  training.  On  each  line,  white  boxes  are  used  to  represent  activities  (tasks) 
that  each  organization  performs  to  support  or  provide  training.  The  gray  boxes  show  the 
inputs  and  outputs  of  information  that  operational  activities  share  with  other  operational 
activities.  Additionally,  the  figures  also  indicate  a  direction  of  flow.  Parallel  lines  show 
that  organizations  are  performing  their  set  of  operational  activities  congruently.  The  order 
of  the  operational  activities  shows  that  an  organization  may  have  to  perform  some 
activities  before  others.  Finally,  the  arrows  coming  in  and  out  of  the  grey  boxes  show 
what  operational  activities  are  producing  and  providing  for  other  operational  activities. 

b.  OFRP  Illustrations 

The  following  four  figures  provide  an  overview  illustrating  the  complexity  related 
to  the  conduct  of  sustainment,  integrated,  and  basic  training.  These  figures  are  not  all 
inclusive  of  the  detailed  intricacies  of  the  Navy’s  organization,  but  are  useful  in  showing 
the  general  organizations  involved,  the  activities  they  perform,  and  the  information  they 
share  in  the  training  environment. 
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As  shown  in  Figure  12,  operational  activities  or  tasks  of  providing  training  in  each 
of  the  basic,  integrated,  and  sustainment  phases  of  the  OFRP  are  conducted  in  parallel. 
Each  one  of  the  three  tasks  is  broken  down  into  sub-tasks  or  sub-operational  activities. 


Figure  12.  Operational  Activity  Overview 

Figure  13  depicts  the  operational  activities  that  the  TYCOM,  Certification 
Programs,  Fleet  Level  Training  Facilities,  and  CSG/ESG  Units  perform  to  facilitate 
training  during  the  basic  phase  of  the  OFRP.  The  left  side  shows  just  the  operational 
activities  while  the  right  side  shows  the  inputs  and  outputs  of  the  operational  activities. 
For  more  details,  see  Appendix  B,  which  lists  the  inputs  and  outputs  of  each  operational 
activity  along  with  the  organization  that  performs  that  activity. 
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Figure  13.  Basic  Training  Overview 
48 


Figure  14  depicts  the  operational  activities  that  the  Numbered  Fleet  Commander, 
Tactical  Training  Group,  CSG/ESG  Commander,  Fleet  Level  Training  Facilities,  and 
CSG/ESG  Units  perform  to  facilitate  training  during  the  integrated  phase  of  the  OFRP. 
The  left  side  shows  just  the  operational  activities  while  the  right  side  shows  the  inputs 
and  outputs  of  the  operational  activities.  For  more  details,  see  Appendix  B,  which  lists 
the  inputs  and  outputs  of  each  operational  activity  along  with  the  organization  that 
performs  that  activity. 
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Figure  14.  Integrated  Training  Overview 
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Figure  15  shows  the  operational  activities  that  the  Numbered  Fleet  Commander, 
CSG/ESG  Commander,  and  CSG/ESG  Units  perform  in  order  to  facilitate  training  during 
the  sustainment  phase  of  the  OFRP.  The  left  side  shows  just  the  operational  activities 
while  the  right  side  shows  the  inputs  and  outputs  of  the  operational  activities.  For  more 
details,  see  Appendix  B,  which  lists  the  inputs  and  outputs  of  each  operational  activity 
along  with  the  organization  that  performs  that  activity. 
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Figure  15.  Sustainment  Training  Overview 
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V.  GAP  ANALYSIS 


Through  research,  interviews  with  stakeholders,  and  the  development  of  a  concept 
of  operations  for  the  WFTS,  the  team  identified  critical  gaps  in  the  Navy’s  training 
system  that  will  prevent  the  future  warfighter  from  effectively  and  efficiently  employing 
webfires.  Identification  of  these  gaps  is  critical  in  the  systems  engineering  process 
because  any  proposed  solution  must  address  known  gaps.  Systems  engineers  can  use  the 
identified  gaps  to  help  develop  capability  requirements  that  a  system  must  possess  in 
order  “to  meet  an  organization’s  role,  functions,  and  missions  in  current  or  future 
operations”  (Defense  Acquisition  University  2017).  After  capability  gaps  have  been 
determined,  the  concept  of  operations  (CONOPS)  can  be  fully  developed  to  describe  how 
the  future  system  will  address  these  gaps.  This  CONOPS  is  useful  to  determine  capability 
requirements  that  will  then  drive  the  rest  of  the  system  architecture  that  will  be  developed 
to  address  the  defined  gaps. 

A.  IDENTIFIED  GAPS 

“Gap  Analysis  is  the  comparison  of  actual  performance  with  potential  or  desired 
performance;  that  is,  the  ‘current  state’  the  ‘desired  future  state’”  (Emery  2017).  The 
following  paragraphs  discuss  each  gap  in  detail  to  explain  how  the  current  system 
struggles  in  meeting  a  gap  and  why  the  gap  is  important  to  webfires  training.  The  team 
discovered  four  major  gaps  during  our  research.  Some  of  the  major  gaps  have  multiple 
factors,  which  are  expanded  upon  to  provide  background  and  an  understanding  of  the 
nature  of  the  gap. 

1.  Lack  of  Webfires  Concept  Training 

The  development  of  the  webfires  concept  necessitates  the  development  of  a 
webfires  training  system.  No  other  current  training  systems  meet  the  unique  requirements 
for  a  highly  integrated  warfare  system.  Limited  elements  of  the  needed  training  have  been 
implemented,  including  NIFA-CA  located  in  Fallon,  NV;  however,  no  overall  centralized 
solution  has  thus  far  been  developed. 
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2.  Lack  of  Multi-Unit  Training  Repetition  to  Support  Additional 
Webfires  Training  Requirements 

The  team  considers  the  inability  to  perform  quality  repetitions  as  the  most 
significant  limitation  to  integrated  training.  Current  training  allocates  limited  time  and 
resources  during  the  integrated  phase  of  training.  While  the  traditional  model  is  sufficient 
for  today’s  battlespace,  the  webfires  construct  relies  heavily  on  integrated  tactics  that 
must  be  practiced  and  improved  upon.  A  significant  increase  in  resources,  including 
funding  and  time,  would  provide  a  measureable  increase  in  overall  CSG/ESG 
performance.  A  number  of  identified  factors  also  hinder  the  ability  to  perform  multiple 
iterations  of  integrated  training.  Following  is  a  detailed  list  of  factors  that  contribute  to 
this  gap  and  the  training  architecture  will  address. 

a.  Lack  of  Standardized  Multi-Unit  Scenarios  for  Training 

The  current  approach  to  integrated  training  relies  on  third-party  shore -based 
training  groups,  such  as  TACTRAGRUPAC/LANT,  to  provide  pre-programmed 
scenarios  for  use  in  the  integrated  environment.  These  scenarios  are  difficult  and 
expensive  to  produce  and  stage,  and  are  unable  to  be  performed  independent  of  these 
third-party  organizations.  This  hinders  training  multiple  CSG/ESG.  Additionally,  the 
range  at  which  the  training  can  be  conducted  is  reduced  due  to  the  line-of-sight 
limitations  of  these  radio-operated  networks.  Providing  the  CSG/ESG  the  ability  to  create 
and  run  their  own  training  scenarios  that  focus  on  the  specific  threats  in  an  area  of 
responsibility  (AOR)  can  greatly  improve  training  quality  and  relevance. 

b.  Lack  of  Communications  Bandwidth  between  Ships  and  Simulators 

Currently,  integrated  training  relies  heavily  on  using  real  communications  circuits 
to  conduct  training.  The  issue  with  this  approach  is  that  communications  circuits  are 
limited  in  bandwidth  and  are  often  prioritized  for  military  operations,  thus  limiting  time 
and  resources  for  effective  training.  Additionally,  units  must  periodically  conduct  routine 
maintenance  on  their  communications  systems,  which  can  limit  a  unit’s  capability  to 
perform  integrated  training. 
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c.  Lack  of  Resources  at  TTGs  to  Support  Multiple  Training  Simulations 
Simultaneously 

Currently  integrated  training  relies  heavily  on  a  central  node  (TTGP/L)  to 
establish  communication  and  simulation  links  to  perform  a  controlled  scenario.  This 
reduces  the  frequency  of  training  events  and  limits  the  warfighter’s  ability  to  perform 
multiple  repetitions  to  increase  his  or  her  proficiency.  Increasing  the  physical  data 
processing  capability  would  not  completely  solve  the  issue.  These  facilities  rely  heavily 
on  experts  who  are  able  to  evaluate  each  unit’s  performance  and  provide  useful  feedback. 
The  facilities  also  lack  the  number  of  qualified  personnel  who  would  be  required  to 
conduct  more  of  this  type  of  training. 

3.  Lack  of  Compatible  Networks  to  Perform  Multi-Unit  Training 

The  severely  convoluted  and  complex  mix  of  network  types  and  responsible 
parties  that  exists  today  is  incompatible  for  the  integration  required  to  run  the  WFTS.  The 
issue  is  rooted  in  two  primary  areas:  the  lack  of  common  information  assurance  (IA) 
regulations  across  services  and  acquisitions  programs,  and  the  lack  of  a  physical  and 
reliable  network  system  to  connect  live  units  and  simulator  stations. 

a.  Lack  of  Common  IA  Certifications  to  Integrate  Data 

Training  networks  are  developed  to  operate  for  a  specific  purpose,  which  is 
generally  focused  on  serving  the  community  that  acquired  it.  Often  times,  however,  little 
thought  has  been  placed  into  integrating  these  training  networks.  The  attempt  to  integrate 
the  Navy’s  training  network  with  that  of  the  Marine  Corps  is  such  an  example.  The  major 
limitation  is  the  lack  of  common  IA  certifications.  The  certifications  designed  to  protect 
the  data  significantly  hinder  the  ability  to  share  data  over  different  networks  within  the 
DOD.  Other  examples  discovered  during  stakeholder  interviews  demonstrated  that  the 
ability  to  share  data  within  the  Navy’s  own  networks  is  often  artificially  reduced  through 
complex  and  non-standard  IA  requirements. 
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b.  Lack  of  Ability  to  Interface  Units  and  Facilities/Simulators 

Current  training  facilities  were  designed  only  with  their  respective  communities 
(i.e.,  helicopters,  jets,  destroyers,  and  cruisers)  in  mind,  with  little  capability  to  interface 
with  a  different  community.  This  obstacle  is  even  more  apparent  in  attempts  to  interface 
live  units  (i.e.,  deployed  ships,  flying  aircraft)  with  simulators.  Our  research  has  shown 
very  little  capability  exists  to  integrate  these  different  training  environments  into  a 
common  scenario.  To  ensure  the  quality  of  training  required  to  leam  integrated  tactics  for 
employment  of  a  webfires  concept,  these  systems  must  be  able  to  integrate  seamlessly. 

4.  Lack  of  a  Quality  Feedback  Process 

At  the  end  of  any  training  event  the  students  and  instructors  should  gather 
together  to  replay  the  event  and  discuss  the  training  in  detail.  Reviewing  these  details 
allows  the  students  to  recognize  both  the  positive  and  negative  decisions  made  and  any 
possible  future  corrections.  Conducting  training  without  feedback  detracts  from  the 
overall  quality  of  training.  Without  the  opportunity  to  review  and  correct  mistakes  in  a 
timely  manner,  training  quality  and  mission  performance  are  negatively  affected. 

a.  Lack  of  Face-to-Face  Debriefing  by  SMEs  and  Groups  Conducting 
Multi-Unit  Training 

The  aviation  community  has  recognized  these  benefits  and  adopted  a  robust 
feedback  system.  All  involved  pilots  and  instructors  meet  soon  after  each  flight  to  review 
the  training  evolution.  The  use  of  available  video  and  audio  recording  helps  provide  a 
clear  picture  of  the  events  that  took  place.  Additionally,  instructors  provide  feedback 
directly  to  the  students  in  an  open  forum  to  discuss  any  mistakes  or  confusion  during  the 
event.  No  one  should  walk  away  with  any  questions  or  confusion.  This  system,  although 
beneficial,  has  not  been  adopted  by  all  communities.  However,  the  surface  and  sub¬ 
surface  communities  are  beginning  to  implement  various  methods  that  attempt  to  model 
the  aviation  system  with  varying  degrees  of  success. 
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b.  Lack  of  Necessary  Capability  to  Assess  Webfires  Training,  Doctrine,  and 
Procedures  against  a  Near-Peer  Threat 

Current  training  systems  contain  functionality  to  assess  the  progress  and 
effectiveness  of  unit-level  training.  These  tools  focus  on  providing  detailed  analysis  for  a 
single  platform  type.  This  limited  analysis  consequently  isolates  information  required  for 
integrated  analysis.  Determining  the  fleet’s  performance  against  future  near-peer  threats 
requires  the  ability  to  combine  integrated  performance  results  effectively  to  determine 
fleet  tactical  performance. 

c.  Lack  of  Automated  Data  Processing  for  Expedited  Evaluation  of 
Training 

The  current  feedback  process  following  a  fleet  exercise  is  painstakingly  slow. 
Information  processing  times  range  from  hours  to  weeks  depending  on  the  platform  and 
event.  The  webfires  training  system  must  process  results  within  an  event  timeline  to 
produce  desired  training  results  effectively. 

B.  LESSONS  LEARNED 

To  help  identify  the  WFTS  gaps,  the  team  analyzed  past  and  current  training 
systems  installed  on  ships  and  at  training  facilities  to  gain  more  insights.  Based  on  these 
complex  training  systems,  the  team  was  able  to  identify  some  of  the  valuable  lessons 
learned. 

First,  it  takes  a  long  time  to  properly  design  and  install  the  training  system 
onboard  a  ship.  This  is  due  to  several  reasons.  One  reason  is  that  procedures  are  difficult 
to  follow  and  complete  properly.  The  other  reason  is  the  sailor’s  lack  of  training  in 
installing  the  equipment.  Second,  it  takes  a  long  time  to  troubleshoot  the  training  systems. 
Due  to  the  complex  nature  of  the  training  system  hardware  and  software,  the  maintainers 
must  spend  considerable  time  troubleshooting  and  repairing  the  systems.  Third,  there  is 
lack  of  interfaces  between  training  facilities.  Various  contractors  have  designed  and  built 
the  training  systems,  often  making  these  systems  unable  to  communicate  with  each  other 
for  an  integrated  training  event.  Finally,  there  are  many  connectivity  issues  between  ships 
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and  training  facilities.  This  is  due  to  both  the  poor  reliability  of  pier  connections  and  a 
ship’s  scarcity  of  bandwidth. 


58 


VI.  CONCEPT  OF  OPERATIONS 


This  chapter  describes  the  process  by  which  the  proposed  WFTS  will  operate. 
After  defining  the  process,  the  chapter  presents  short  illustrative  stories  to  help  the  reader 
put  the  operations  into  context. 

A.  DEFINITION 

According  to  the  website,  AcqNotes.com  (2017d),  a  resource  archive  for 
acquisitions  and  engineering  professionals  working  in  the  DOD  environment,  a  CONOPS 
is  defined  as: 

CONOPS  is  used  to  examine  current  and  new  and/or  proposed  capabilities 
required  to  solve  a  current  or  emerging  problem.  It  describes  how  a  system 
will  be  used  from  the  viewpoints  of  its  various  stakeholders.  This  provides 
a  bridge  between  the  often  vague  capabilities  that  a  project  begins  with 
and  the  specific  technical  requirements  needed  to  make  is  successful.  A 
CONOPS  is  a  useful  tool  that  helps  the  user  community  write/refine 
[capability  requirements  and  functional  requirements  that  a  system  must 
have  in  order  to  close  the  identified  capability  gaps  and  meet  the  intended 
goals  of  a  system]. 

In  conjunction  with  vignettes  (short  stories  describing  the  system  solving  the 
problem),  the  CONOPS  helps  designers  develop  final  capability  requirements,  system 
requirements,  operational  activities,  and  functions  that  the  system  must  perform  in  order 
to  fill  the  capability  gaps  that  were  previously  identified.  Once  these  steps  have  been 
completed,  an  analysis  of  alternatives  is  conducted  to  determine  the  solution  that  will  best 
fulfill  the  requirements  and  address  the  capability  gaps.  From  the  AcqNotes  website,  the 
purpose  and  objectives  of  a  CONOPS  are  summarized  below. 

1.  Purpose 

•  Aid  in  getting  stakeholder  agreement  on  how  the  system  will  be  operated. 

•  Help  show  high-level  system  concepts  and  aid  in  their  justifications. 

•  Help  define  high-level  requirements. 

•  Define  the  environment  in  which  the  system  will  operate. 
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•  Help  in  the  system  validation  process. 

2.  Objectives 

•  The  goals  and  objectives  of  the  system. 

•  Constraints  affecting  the  system. 

•  Organizations  and  interactions  among  participants. 

This  chapter  begins  by  introducing  the  CONOPS  and  presenting  the  Operational 
View-One  (OV-1)  for  the  proposed  training  system.  It  then  presents  multiple  vignettes 
that  explore  common  scenarios  detailing  how  the  WFTS  will  operate.  These  vignettes 
illustrate  how  webfires  will  enhance  in-port,  underway,  unit,  and  multi-unit  training 
during  the  basic,  integrated,  advanced,  and  sustainment  phases  of  the  OFRP. 

B.  WFTS  CONOPS 

As  shown  in  Table  7,  by  using  technology  such  as  actual  and  simulated 
communication  links,  augmented  reality,  hi-fidelity  simulators,  and  actual  combat 
systems  in  each  phase  of  the  OFRP,  the  scenarios  performed  in-port  and  underway  will 
enable  improved  single  unit  and  multi-unit  training. 


Table  7.  Types  and  Phases  of  Webfires  Training 


Types  of  Training 

OFRP  PHASE 

Basic 

Integrated 

Sustainment 

Unit 

In-Port 

X 

X 

X 

Underway 

X 

X 

X 

Multi-Unit 

In-Port 

N/A 

X 

X 

Underway 

N/A 

X 

X 

Looking  at  Figure  16,  we  see  that  as  units  conduct  training  and  data  is  collected  it 
can  be  used  to  aid  organizations  in  evaluating  and  certifying  units  for  the  next  phase  of 
the  OFRP.  Additionally,  that  data  is  useful  for  evaluating  the  effectiveness  of  training, 
doctrine,  and  procedures  that  are  developed  for  near-peer  threats. 
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If  training,  procedural,  or  doctrinal  gaps  are  discovered,  they  can  be  corrected  and 
delivered  to  the  fleet  in  a  timely  manner.  Additionally,  this  figure  shows  that  SMEs 
associated  with  near-peer  threat  doctrine  and  procedures  can  help  create  and  manage  the 
scenarios  that  are  used  to  train  the  fleet. 


Train 


Update  Training 


Evaluate 


AvVa  1  R 

spurn 


Artificial  Intelligence 
Live  Virtual  Constructive  Training 
Simulation 


High  Velocity  Learning 


Images  from  Navy.mil,  GlobalSecurity.org,  USFFC,  NAVAIR,  NAVSEA,  SPAWAR, 
NWDC,  ONI,  CAE,  IBM,  and  SECNAV. 


Figure  16.  WFTS  CONOPS  Diagram 


C.  VIGNETTES 

A  vignette  is  a  brief  description  that  is  used  to  describe  how  a  system  will  operate 
once  it  has  been  fully  implemented.  These  descriptions  are  useful  in  the  engineering 
process  because  they  can  aid  engineers  in  placing  system  functions,  requirements,  and 
capability  gaps  in  context.  Using  vignettes  engineers  can  creatively  analyze  the  capability 
gaps  and  explore  ways  that  a  system  might  close  those  gaps. 

This  portion  of  the  report  uses  illustrative  descriptions  to  show  how  the  future 
WFTS  can  provide  both  unit  and  multi-unit  training  while  CSG  units  are  in-port  or 
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underway  during  the  basic,  integrated,  and  sustainment  phases  of  the  OFRP.  Although 
these  vignettes  are  useful  in  identifying  future  capabilities,  they  may  not  be  representative 
of  the  final  capabilities  that  the  future  system  will  have. 

1.  In-Port  Unit  Training 

A  ship  has  just  completed  the  maintenance  phase  of  the  OFRP  and  needs  to 
prepare  its  crew  to  deploy  with  a  CSG.  Proficiency  and  currency  are  low  and  the  crew 
needs  to  gain  experience  rapidly  in  order  to  move  forward  to  integrated  training  with  the 
CSG. 

While  in  port,  the  ship’s  crew  takes  turns  running  simple  preprogrammed 
scenarios  on  their  shipboard  systems  that  were  developed  by  SMEs  knowledgeable  about 
enemy  tactics  and  procedures.  The  goal  of  this  training  is  to  help  familiarize  watch 
standers  with  their  consoles  and  equipment,  and  reinforce  current  doctrine,  procedure, 
and  tactics  to  which  they  should  have  been  trained.  Data  is  collected  that  allows  the 
commanding  officer  and  higher  organizations  to  evaluate  the  crew’s  performance  and  to 
determine  the  effectiveness  of  the  training.  This  allows  organizations  to  track  whether  a 
ship  or  unit  needs  special  training  to  aid  in  preparing  for  the  next  phase  of  the  OFRP. 
This  data  could  also  be  used  to  certify  a  unit  is  ready  to  proceed  to  the  integrated  phase  of 
the  OFRP.  During  this  phase  of  training,  if  a  ship  is  unable  to  conduct  onboard  training 
due  to  maintenance  actions  it  will  be  able  to  send  watch  standers  to  a  shore  facility  where 
the  same  scenarios  can  be  run  on  simulated  shipboard  equipment. 

2.  Underway  Unit  Training 

While  preprogrammed  scenarios  are  useful  in  helping  to  train  units,  actual 
training  at  sea  can  greatly  increase  the  training  value  by  interjecting  real  world  events, 
such  as  weather  and  connectivity  issues,  in  communication  systems.  Adding  the  extra 
dimension  of  realism  allows  watch  standers  to  receive  more  realistic  training  and  better 
prepare  them  for  a  near-peer  threat.  Simulation  adds  value  in  training  but  reliance  on  too 
much  simulation  in  the  future  can  also  be  a  disadvantage. 
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During  this  type  of  training,  a  ship  can  run  preprogrammed  scenarios  that 
simulate  real  contacts  through  augmented  reality.  For  instance,  a  ship  can  practice 
maneuvering  to  track  and  then  attack  a  simulated  submerged  threat.  As  previously 
mentioned,  data  will  be  recorded  to  allow  the  ship  and  other  organizations  to  evaluate 
performance  and  help  certify  the  unit  is  ready  to  proceed  to  the  integrated  phase  of  the 
OFRP.  Additionally,  more  advanced  simulations  can  be  produced  to  simulate  friendly 
ships  and  aircraft  to  aid  individual  units  in  aspects  of  training  that  will  be  required  for  the 
integrated  and  sustainment  phases  of  the  OFRP. 

3.  Multi-Unit  Training  During  the  Integrated  Phase 

While  in  port,  any  combination  of  multiple  ships,  aircraft  simulators,  and  ship 
simulators  can  connect  to  a  network  that  will  allow  them  to  simulate  the  real  world 
communications  necessary  to  employ  webfires  as  well  as  allow  them  to  simulate  a  shared 
scenario.  This  simulation  can  be  a  preprogrammed  scenario  during  the  beginning  of  the 
integration  phase,  or  it  can  consist  of  highly  choreographed  scenarios  managed  by  a 
training  organization  during  later  phases  of  the  integration  and  sustainment  phases. 

All  of  the  friendly  units  are  played  by  the  actual  units  that  will  be  deploying 
together  as  a  CSG  or  ESG.  The  location  of  each  of  those  units  is  simulated  as  underway 
in  the  area  in  which  they  will  be  deploying.  Expected  opposition  forces  are  developed, 
simulated,  and  controlled  by  SMEs  at  the  relevant  tactical  training  groups  to  provide 
high-fidelity  enemy  actions  and  responses  during  the  more  advanced  stages  of  the 
integrated  phase.  Despite  the  geographical  separation  between  the  participants,  some  out 
to  sea,  some  in  port,  and  some  unable  to  use  their  own  ship’s  systems  due  to  equipment 
casualties,  the  entire  strike  group  is  able  to  integrate  into  a  common  operating  picture  to 
conduct  integrated  training. 

Like  single-unit  training,  data  from  multi-unit  training  can  be  recorded  and  used 
by  organizations  to  help  evaluate  and  certify  units  to  continue  into  the  next  phase  of  the 
OFRP  or  for  deployment.  Additionally,  during  these  advanced  threat  scenarios,  data  can 
be  recorded  to  evaluate  the  effectiveness  of  current  doctrine,  procedure,  and  tactics 
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employed  by  the  fleet.  If  discrepancies  are  found,  or  more  efficient  means  of  prosecuting 
a  target  are  discovered,  the  TTPs  can  be  updated  accordingly. 

4.  Underway  Sustainment  Phase  Training 

During  this  type  of  training,  each  unit  can  carry  equipment  (permanently  installed 
or  temporary)  that  will  allow  the  unit  to  form  and  utilize  a  webfires  network.  For  this 
exercise,  each  unit  has  put  its  system  in  training  mode,  allowing  the  unit  to  send  and 
receive  simulated  combat  data,  shared  by  a  common  network  seen  by  all.  The  servers 
needed  to  run  the  simulation  software  will  be  primarily  housed  on  the  aircraft  carrier  at 
the  heart  of  the  strike  group.  Other  surface  units  have  server  racks  that  can  help  process 
and  relay  webfires  data  on  a  smaller  scale  in  the  carrier’s  absence. 

With  the  simulation  processing  capability  resident  to  the  strike  group,  no 
connection  back  to  the  training  centers  on  land  is  needed.  SMEs  embedded  in  the  strike 
group  in  the  form  of  Weapons  and  Tactics  Instructors  control  the  opposition  forces  and 
provide  a  sense  of  realism  to  enemy  actions.  Only  the  enemies  and  the  weapons  are 
simulated.  For  example,  real  fighters  fly  against  computer- simulated  aircraft,  and  ships 
execute  real  maneuvers  against  simulated  submarine  threats.  Real  communications  and 
real  console  operations  take  place  in  training  mode.  For  most  console  operators,  there 
should  be  no  appreciable  difference  between  the  simulated  combat  scenario  on  their 
consoles  and  what  would  appear  on  the  consoles  during  actual  combat. 
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VII.  SYSTEM  REQUIREMENTS 


After  determining  the  capability  gaps  and  the  concept  of  operations  of  the  new 
system,  the  next  step  in  the  systems  engineering  process  is  to  identify  the  requirements 
that  the  system  must  fulfill  in  order  to  bridge  those  gaps  while  meeting  the  goals  of  the 
CONOPS.  Requirements  form  the  basis  of  the  future  system  design.  All  functions  and 
operational  activities  that  a  system  possesses  must  fulfill  all  the  stated  requirements. 
Those  functions  and  operational  activities  can  then  be  used  to  assign  tasks  to  operational 
nodes  and  components  to  meet  system  functions.  For  the  purpose  of  this  report,  there  are 
two  basic  types  of  requirements:  capability  requirements  and  functional  requirements. 
These  are  described  in  detail  in  the  following  sections. 

A.  CAPABILITY  REQUIREMENTS 

A  capability  requirement  (also  known  as  an  operational  requirement)  is  a 
requirement  delineating  a  capability  that  a  system  must  have  in  order  to  meet  the 
missions  of  a  system  (Defense  Acquisition  University  2017).  Capability  requirements 
directly  relate  to  the  CONOPS  and  how  the  future  system  will  be  employed  to  provide 
training  and  address  the  capability  gaps  identified  in  Chapter  V. 

These  capability  requirements  are  a  driving  factor  in  the  system  architecture  for 
the  WFTS  because  capabilities  are  addressed  by  tasks  that  the  system  must  accomplish. 
These  tasks  are  then  implemented  by  system  functions,  which  are  performed  by  system 
components. 

If  capability  requirements  are  not  fully  developed,  it  is  possible  that  a  system  is 
built  that  does  not  adequately  perform  the  missions  of  that  system.  Using  capability  gaps 
and  the  CONOPS  developed  earlier,  the  following  capability  requirements  were 
developed.  Each  requirement  is  described  in  detail  as  this  section  maps  the  capability 
requirements  to  the  capability  gap(s)  that  it  addresses. 
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1.  Training  Requirements 

These  are  requirements  that  directly  focus  on  training  the  warfighter.  These 
requirements  focus  on  when,  where,  and  how  a  warfighter  and  unit  can  train. 

a.  The  System  Shall  Integrate  Webfires  Concept  Training  during  the 
Basic ,  Integrated,  and  Sustainment  Phases  of  the  OFRP 

By  integrating  the  WFTS  into  the  basic,  integrated,  and  sustainment  phases  of  the 
OFRP,  units  can  train  on  webfires  concepts  throughout  their  entire  training  cycle  prior  to 
deployment  and  maintain  their  proficiency  to  use  webfires  after  deployment.  By 
introducing  elements  of  webfires  training  into  the  OFRP  cycle  during  the  basic  phase, 
units  will  progress  though  the  integrated  phase  with  greater  proficiency  and  will  then  be 
more  capable  to  fight  a  near-peer  threat  while  on  deployment  or  during  the  remainder  of 
the  sustainment  phase.  This  will  introduce  integrated  training  in  the  basic  phase  through 
simulation. 

b.  The  System  Shall  Integrate  Webfires  Concept  Training  during  Unit  and 
Multi-Unit  Training 

The  nature  of  the  webfires  concept  is  to  integrate  units  together  to  process  a 
target.  The  integration  of  this  training  during  unit  and  multi-unit  training  exercises  will 
better  prepare  units  to  work  together  to  defeat  a  near-peer  threat.  Integrating  webfires 
concept  training  into  unit  training  exercises  will  allow  individual  units  to  focus  on 
specific  training  deficiencies  that  need  improvement  prior  to  conducting  multi-unit 
training. 


c.  The  System  Shall  Integrate  Webfires  Concept  Training  In-port  and  Out- 
to-Sea 

By  integrating  webfires  training  with  units  in  port  and  at  sea,  units  will  better  be 
able  to  practice  the  skills  necessary  to  perform  webfires,  regardless  of  location  or 
underway  schedules. 
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2.  Repetition  Requirements 

These  requirements  focus  on  increasing  the  number  of  repetitions  that  warfighters 
can  do  with  respect  to  training.  Repetitive  high  quality  training  will  help  increase 
retention  of  skills  and  knowledge. 

a.  The  System  Shall  Provide  Standardized  Training  Scenarios  for  Unit  and 
Multi-Unit  Training 

Standardized  scenarios  enable  units  to  have  a  set  of  standards  by  which  they  can 
be  trained  to  fight  a  near-peer  threat.  This  will  also  allow  units  to  train  to  quality 
scenarios  that  are  provided  by  SMEs  on  the  enemy  and  the  tactics  that  they  employ.  By 
using  these  standardized  scenarios,  units  will  not  have  to  create  their  own  and  will  be  able 
to  perform  quality  training  with  greater  frequency. 

b.  The  System  Shall  Provide  Training  with  Limited  Communications 

By  providing  training  in  limited  communications  environments  or  in  port,  units 
will  not  have  to  rely  heavily  on  real  communications  circuits  or  outside  entities  to  provide 
communications.  Thus,  units  will  be  able  to  perform  more  training. 

c.  The  System  Shall  Be  Capable  of  Allowing  Units/Simulators  to 
Independently  Establish  Training  Simulations  with  Other  Units 

By  allowing  units  or  simulators  to  run  simulations  or  scenarios  with  other  units, 
multiple  units  can  train  independently  from  one  another  during  all  phases  of  the  OFRP. 
This  will  allow  units  to  practice  integrated  operations  earlier  in  work-ups  and  prior  to 
deployment,  and  will  increase  the  quality  of  the  training.  Additionally,  this  means  that 
units  will  not  have  to  rely  on  some  other  entity  to  establish  a  training  scenario  for  them 
and  will  allow  multiple  units  to  perform  multiple  multi-unit  scenarios  at  the  same  time. 

d.  The  System  Shall  Integrate  with  and  Be  Capable  of  Integrating  with 
Current  and  Future  Strike  Group  Units ,  Networks ,  and  Training 
Facilities/Simulators 

This  will  allow  units  to  conduct  training  using  their  own  systems  instead  of 
relying  on  simulators  that  may  not  be  the  actual  equipment  that  sailors  will  use  in  combat. 
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Furthermore,  this  capability  should  allow  simulator  facilities  to  link  up  and  conduct 
exercises  with  actual  units.  This  will  increase  the  quality  of  the  training  and  allow  for 
training  to  be  done  more  frequently  in  port  and  at  sea. 

3.  Feedback  Requirements 

These  requirements  focus  on  feedback  that  can  aid  high-velocity  learning. 
Repetition  is  useful;  however,  if  warfighters  are  not  training  correctly  or  more  effectively 
then  the  value  of  that  repeated  training  is  less  productive. 

a.  The  System  Shall  Provide  Data  that  Can  Be  Used  to  Assess  Effectiveness 
of  Training,  Doctrine,  and  Procedures  against  a  Near-Peer  Threat 

By  providing  this  data,  warfare  experts  can  evaluate  the  effectiveness  of  the 
training  and  determine  whether  units  need  more  attention  to  better  prepare  them  for 
deployment.  Additionally,  this  data  is  useful  for  informing  the  developers  of  tactics, 
doctrine,  and  procedures  about  the  effectiveness  of  these  elements  against  a  simulated 
near-peer  threat,  allowing  the  TTPs  to  be  updated  as  necessary. 

b.  The  System  Shall  Provide  Data  that  Can  Be  Used  to  Evaluate  and 
Certify  Units  during  the  OFRP  Cycle 

The  system  can  provide  data  that  is  useful  to  certify  units,  and  this  can  reduce  the 
time  and  separate  certification  requirements  that  units  must  meet  in  order  to  advance  to 
the  next  phase  of  training. 

4.  Summarized  Capability  Gaps 

For  the  reader’s  benefit  in  correlating  the  requirements  and  gaps,  the  following 
list  summarizes  the  capabilities  gaps  that  where  identified  in  Chapter  V. 

1 .  Lack  of  Webfires  Concept  Training 

2.  Lack  of  Multi-Unit  Training  Repetition  to  Support  Additional  Webfires 
Training  Requirements 

a.  Lack  of  Standardized  Multi-Unit  Scenarios  for  Training 
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b.  Lack  of  Communications  Bandwidth  between  Ships  and 
Simulators 

c.  Lack  of  Resources  at  TACTRAGRUPAC/LANT  to  Support 
Multiple  Training  Simulations  Simultaneously 

3.  Lack  of  Compatible  Networks  to  Perform  Multi-Unit  Training 

a.  Lack  of  Common  IA  Certifications  to  Integrate  Data 

b.  Lack  of  Ability  to  Interface  Units  and  Facilities/Simulators 

4.  Lack  of  a  Quality  Feedback  Process 

a.  Lack  of  Face-to-Face  Debriefing  by  SMEs  and  Groups  Conducting 
Multi-Unit  Training 

b.  Lack  of  Necessary  Capability  to  Assess  Webfires  Training, 
Doctrine,  and  Procedures  against  a  Near-Peer  Threat 

c.  Lack  of  Automated  Data  Processing  for  Expedited  Evaluation  of 
Training 

The  mapping  (traceability)  of  each  capability  requirement  to  a  corresponding  gap 
is  shown  in  Table  8.  By  mapping  the  capability  requirements  to  the  capability  gaps,  the 
systems  engineer  introduces  traceability  and  can  ensure  that  the  new  system  is  addressing 
the  identified  capability  gaps.  Failure  to  ensure  that  each  capability  gap  identified  is  being 
addressed  would  result  in  a  system  that  fails  to  meet  the  needs  of  the  stakeholders. 

The  WFTS  as  envisioned  in  this  report  is  unable  to  address  capability  gaps  3a  and 
4a  at  this  time.  After  thorough  discussion,  the  team  determined  that  these  specific  gaps 
are  outside  the  scope  of  this  report  and  will  be  recommended  as  future  research  topics. 
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Table  8.  Mapping  Capability  Requirements  to  Capability  Gaps 


Capability 

Gap 

Capability 

Requirement 

Discussion 

1 

la-lc 

A  system  designed  to  integrate  webfires  into  unit  and 
multi-unit  training  while  at  sea  or  in  port  during  the 
basic,  integrated,  and  sustainment  training  phases  of  the 
OFRP  will  address  the  gap  of  no  current  webfires 
concept  training  currently  exists. 

2a 

2a 

Preprogrammed  scenarios  will  address  the  gap  of  no 
preprogrammed  scenarios. 

2b 

2b 

The  ability  to  train  with  limited  communications  will 
address  the  lack  of  communications  bandwidth  between 
ships  and  simulators. 

2c 

2c 

The  capability  of  units/simulators  to  establish  their  own 
scenarios  will  address  the  gap  of  having  to  rely  on  the 
limited  resources  of  TACTRAGRUPAC/LANT. 

3a 

N/A 

The  WFTS  will  not  address  this  capability  gap. 

3b 

3 

The  WFTS’  capability  to  integrate  with  all  units/ 
simulators  will  address  the  gap  of  lacking  the  ability  to 
interface  units  and  simulators. 

4a 

N/A 

The  WFTS  will  not  address  this  capability  gap. 

4b 

4a 

Data  provided  by  the  new  training  system  will  fill  gap  of 
the  current  training  system  in  providing  the  capability  to 
assess  training,  doctrine,  tactics,  and  procedures. 

4c 

4b 

Data  provided  by  the  new  system  will  allow  for  faster 
evaluation  and  certification  of  training. 

B.  FUNCTIONAL  REQUIREMENTS 

“A  functional  requirement  is  simply  a  task  (sometimes  called  an  action  or 
activity)  that  must  be  accomplished  to  provide  an  operational  capability  (or  satisfy  an 
operational  requirement)”  (AcqNotes  2017c).  These  functional  requirements  used  to 
determine  the  functions  that  the  components  (hardware  and  software)  of  the  system  must 
perform  in  order  to  satisfy  the  capability  requirements  and  close  the  gaps  that  were 
identified. 

Functional  requirements  are  derived  from  capability  requirements  and  are  used  to 
help  develop  system  functions.  Later  in  the  systems  engineering  process,  these  functions 
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help  to  identify  design  alternatives  and  conduct  an  analysis  of  alternatives.  The  functional 
requirements  identified  for  the  WFTS  include: 

1.  The  system  shall  be  able  to  integrate  with  all  CSG/ESG  units’  weapons 
systems  capable  of  conducting  webfires. 

2.  The  system  shall  be  able  to  interface  with  current  and  future  webfires 
capable  training  facilities  and  simulators. 

3.  The  system  shall  be  able  to  receive  updates  from  the  intelligence 
community  of  current  enemy’s  threats. 

4.  The  system  shall  be  compatible  with  existing  networks  and  ship  systems. 

5.  The  system  shall  be  able  to  provide  standardized  preprogramed 
simulations  to  the  warfighters. 

6.  The  system  shall  provide  the  ability  for  units  to  modify  preprogrammed 
simulations. 

7.  The  system  shall  provide  the  ability  for  units  to  create  simulations. 

8.  The  system  shall  provide  the  ability  for  multiple  units  and  training 

facilities  to  conduct  the  same  integrated  training  scenarios  simultaneously. 

9.  The  system  shall  support  multiple  simulations  running  concurrently. 

10.  The  system  shall  support  the  simulations  being  controlled  by  units, 
simulators,  or  commanders. 

11.  The  system  will  support  the  storage  of  simulations  in  a  simulation  bank. 

12.  The  system  shall  collect  and  provide  data  that  can  be  used  to  evaluate  the 

performance  of  the  training  system. 

13.  The  system  shall  collect  and  provide  data  that  can  be  used  to  certify  and 
evaluate  units. 

14.  The  system  shall  use  communication  circuits  available  in  2025-2030. 

C.  REQUIREMENTS  SUMMARY 

This  chapter  discussed  the  capability  requirements  and  functional  requirements 
that  the  webfires  concept  must  possess  in  order  to  fill  the  capability  gaps.  The  capability 
requirements  were  then  used  to  determine  functional  requirements  that  will  help  the 
system  meet  the  capability  requirements.  Both  the  functional  requirements  and  capability 
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requirements  will  be  used  to  determine  the  operational  activities  (people/organizational 
functions)  that  the  system  must  have  and  the  system  functions  (hardware/software)  that 
the  system  must  possess  to  fulfill  these  capability  requirements  and  functional 
requirements.  These  operational  activities  and  system  functions  also  help  identify 
possible  design  alternatives  that  are  discussed  later  in  more  detail  in  Chapter  IX. 
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VIII.  FUNCTIONAL  ANALYSIS 


A.  FUNCTIONAL  ANALYSIS 

Functional  analysis  is  a  critical  step  in  the  systems  engineering  process.  This 
analysis  is  performed  in  the  conceptual  design  phase  of  any  project  that  seeks  to  translate 
top-level  system  requirements  into  meaningful  design  criteria  (Blanchard  and  Fabrycky 
2011,  86):  “A  function  refers  to  a  specific  or  discrete  action  (or  series  of  actions)  that  is 
necessary  to  achieve  a  given  objective  [and]  may  ultimately  be  accomplished  through  the 
use  of  equipment,  software,  people,  facilities,  data,  or  various  combinations  thereof’  (86). 

[Functional  analysis  is  an  iterative  process  of  translating  system 
requirements  into  detailed  design  criteria  and  the  subsequent  identification 
of  the  resources  required  for  system  operation  and  support.  It  includes 
breaking  requirements  at  the  system  level  down  to  the  subsystem,  and  as 
far  down  the  hierarchical  structure  as  necessary  to  identify  input  design 
criteria  and/or  constraints  for  the  various  elements  of  the  system.  The 
purpose  is  to  develop  the  top-level  system  architecture,  which  deals  with 
both  “requirements”  and  “structure.”  (Blanchard  and  Fabrycky  2011,  86) 

Using  tools  such  as  functional  decompositions  and  functional  flow  block 
diagrams,  engineers  can  determine  the  functions  that  a  system  must  have  in  order  to  meet 
system  requirements.  This  ensures  that  all  requirements  are  being  met  by  the  system;  it  is 
imperative  that  engineers  verify  that  system  requirements  are  traceable  to  each  of  the 
established  system  functions. 

B.  SYSTEM  FUNCTIONS 

Within  the  architecture  for  the  WFTS,  the  team  determined  that  there  were 
numerous  functions  that  must  be  accomplished  in  order  to  meet  the  requirements  laid  out 
in  Chapter  VII.  These  primary  functions  are  depicted  in  Figure  17. 
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Figure  17.  WFTS  Primary  Functions 


Furthermore,  within  each  primary  function,  various  sub-functions  are  needed  to 
achieve  the  overall  goal  of  the  WFTS.  To  facilitate  the  hierarchy  between  these  sub¬ 
functions,  a  functional  decomposition  structure  is  created  for  each  primary  function. 

1.  Provide  Simulation 

Within  the  Provide  Simulation  function  of  the  WFTS,  the  first  level  hierarchy  is 
shown  in  Figure  18. 


Figure  18.  Provide  Simulation  Functional  Hierarchy 


a.  Receive  and  Store  Simulations 

As  a  basis  for  training,  especially  with  consideration  to  high-velocity  learning,  the 
WFTS  must  be  able  to  receive  and  store  simulations  as  published  by  the  designated 
training  leader  during  all  stages  of  the  OFRP.  At  the  heart  of  multi-domain  training  is  a 
common  goal  to  be  achieved  for  a  given  state.  Based  on  what  training  simulation  would 

be  needed  or  expected  to  prepare  warfighters  for  their  deployment  to  various  AORs, 
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simulations  would  be  given  to  all  participating  units  from  the  theater  commander. 
Correspondingly,  each  unit  would  need  to  store  and  readily  obtain  a  training  scenario 
from  a  WFTS  simulation  database. 

b.  Create  and  Modify  Simulations 

The  WFTS  must  be  able  to  quickly  adapt  to  changing  tactics,  differing  missions, 
geopolitical  limitations,  regulatory  changes,  etc.  With  such  a  plethora  of  variables  that 
could  potentially  impact  any  number  of  missions,  the  training  scenarios  must  be 
tailorable  to  mimic  conditions  that  are  to  be  expected  throughout  the  world  in  varying 
theaters.  Commanders  will  need  to  be  able  to  either  create  a  simulation  from  scratch,  or 
be  able  to  change  any  variables  (referred  to  as  “technical  injects”)  prior  to  enacting  a 
simulation.  Potential  changes  to  force  levels,  maneuverability  restrictions,  battle  damage, 
participating  units,  etc.,  will  affect  the  fidelity  of  the  training.  Additionally,  intelligence 
updates  must  be  programmable  into  the  simulations. 

c.  Receive  Intel  Updates 

Actively  inviting  intelligence  agencies’  inputs  regarding  potential  enemy  tactics 
and  weapons  would  enhance  the  fidelity  of  scenarios — especially  the  simulation  of  these 
near-peer  red  forces  in  a  cross-domain  campaign  simulation.  Intelligence  update  data 
must  be  programmed  into  the  system  as  expeditiously  as  possible. 

2.  Communicate 

At  the  most  basic  level,  the  communication  structure  of  the  WFTS  must  maintain 
the  ability  for  data  and  voice  communications  to  reach  the  warfighters  reliably  and 
effectively.  This  must  occur  prior,  during,  and  after  any  simulation  or  scenario  is  run  on 
the  variety  of  platforms  with  which  the  system  will  interact.  These  networks  must  be  able 
to  operate  completely  independently  no  matter  where  the  units  or  simulators  are 
physically  located  (i.e.,  in  port  or  underway).  A  hierarchy  of  this  function  is  shown  in 
Figure  19. 
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Figure  19.  Communicate  Functional 

a.  Transmit  Data/Voice/Simulations 

In  the  2025-2030  timeframe  for  which  the  WFTS  is  designed,  networks  are 
assumed  to  be  established  for  cross-domain  communications.  These  various  wired  and 
wireless  networks  shall  provide  the  means  to  transmit  data  (for  both  the  simulations 
themselves  and  the  information  gathered  after  running  them)  and  voice  signals  before, 
during,  and  after  scenarios. 

3.  Conduct  Simulation 

Each  time  the  WFTS  runs  a  simulation  or  scenario,  it  must  be  controlled  by  either 
human  operators  or  artificial  intelligence  algorithms.  This  control  will  not  only  be  within 
the  organization  that  has  cognizant  control  over  the  conduct  of  all  the  players,  but  also 
within  the  equipment  and  simulators  that  are  used.  The  functional  hierarchy  for  this  is 
shown  in  Figure  20. 
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Figure  20.  Conduct  Simulation  Functional  Hierarchy 
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a.  Control  Simulations 

At  any  time,  a  participant  unit  in  a  scenario  will  perform  tasks  based  on 
parameters  such  as  previous  training,  human  factors,  and  available  information.  The 
scenario  lead  must  establish  the  beginning,  end,  and  desired  pauses  while  the  scenario  is 
running.  Therefore,  the  system  must  allow  the  assigned  lead  to  maintain  control.  In 
addition,  simulation  modifications,  such  as  technical  injects,  may  occur  after  a  scenario 
has  been  initiated.  The  lead  must  be  able  to  control  what  information  changes  in  real  time 
to  allow  for  more  realistic  and  effective  training. 

b.  Stimulate  Sensors  Onboard  Units  and  Simulators 

With  the  linking  of  units  to  simulators  during  a  WFTS  scenario,  maximum 
fidelity  and  learning  will  occur  if  the  warfighter  is  able  to  see  what  he  or  she  would  see  in 
an  actual  event.  Therefore,  it  is  paramount  to  ensure  that  equipment,  both  within  the 
simulator  tool  and  aboard  actual  ships,  reacts  properly:  giving  actual  displays  that 
correspond  to  what  should  be  expected  in  a  combat  environment. 

4.  Interface  with  Network 

The  network  that  provides  the  backbone  for  the  WFTS’  operation  must 
accomplish  two  main  interface  functions — interaction  with  the  human  end-users  of  the 
system  and  interaction  of  system  components  in  an  information  technology  infrastructure. 
Figure  21  depicts  this  hierarchy,  which  is  expanded  in  the  following  discussion. 
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Figure  21.  Interface  with  Network  Functional  Hierarchy 
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a.  Interface  with  Human 

The  WFTS  will  utilize  the  latest  technology  for  relaying  information  as  quickly  as 
possible.  This  information  will  include  such  data  as  the  effect  of  the  unit’s  actions, 
probability  of  kill,  and  other  vital  tactical  information.  The  graphical  display  will  be 
designed  to  mimic  what  information  would  be  provided  during  an  actual  engagement. 
Additionally,  displays  for  the  scenario  lead  or  training  commander  will  allow  for 
immediate  feedback  regarding  individual  unit  effectiveness  and  level  of  preparedness  for 
each  unit’s  corresponding  OFRP  phase.  These  functions  are  shown  in  Figure  22. 
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Figure  22.  Interface  with  Human  Functional  Hierarchy 


As  a  complement  to  activation  of  shipboard  equipment  during  a  unit-to-unit  or 
simulator-to-unit  scenario,  WFTS  will  interact  with  warfighters  via  sensors  or  indications 
on  equipment  that  they  are  familiar  with,  to  enhance  tactical  effectiveness. 

b.  Interface  with  System 

WFTS  has  an  extensive  relationship  between  the  various  systems  aboard  a  unit 
and  at  simulation  facilities.  This  is  where  the  major  benefits  of  the  systems  can  truly  be 
realized  to  accomplish  commander’s  intent.  The  interactions  include  links  from: 

•  Unit-to-unit:  i.e.,  watch  standers  on  surface  ships,  airborne  units,  and  a 
submarine  bridge-team 

•  Unit-to-simulator:  i.e.,  USMC  pilots  in  shore-based  simulator,  and 
submarine  bridge-team 
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•  Simulator-to-simulator:  i.e.,  Surface  Officer  Warfare  School  simulator  and 
P-3  simulator 

Information  will  travel  via  the  aforementioned  communication  networks  to 
achieve  these  connections.  These  functions  are  depicted  in  Figure  23. 


Figure  23.  Interface  with  System  Secondary  Functional  Hierarchy 


(1)  Provide  Multi-Unit  Network 

The  network  simulations  will  be  run  by  units  or  in  simulators.  The  latter 
representing  a  shore -based,  established  training  facility.  The  units  can  either  be 
networked  in  port,  via  shore  command,  control,  and  communication  (C3)  facilities,  or  by 
at  sea  C3  networks. 

(2)  Provide  Standalone  Network 

Due  to  the  limited  bandwidth  potential  or  threat  of  operating  in  a  denied/degraded 
environment,  WFTS  simulations  must  be  able  to  operate  via  standalone  systems.  Each 
unit  will  need  the  ability  to  execute  required  training  without  dependence  on  traditional 
at-sea  or  in-port  connections.  Infrastructure  will  include  digital  media  able  to  record 
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results  during  standalone  simulations,  as  well  as  an  ability  to  upload  feedback  data  once  a 
network  is  available. 

5.  Store  Feedback  Data 

In  addition  to  providing  information  instantaneously  to  participants,  the  feedback 
must  be  stored  for  playback  and  analysis  during  the  debrief.  This  can  aid  in  improving 
future  training  (i.e.,  best/worst  practices)  and  individual  unit  performance  metrics.  In  this 
manner,  decision  making  among  WFTS  participants  during  a  simulation  can  contribute  to 
future  modifications  of  TTPs  for  use  in  a  webfires  construct.  A  breakdown  of  functions  is 
shown  in  Figure  24. 
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Figure  24.  Store  Feedback  Data  Functional  Hierarchy 


C.  OPERATIONAL  ACTIVITIES 

After  defining  and  decomposing  the  functions  of  an  optimally  designed  WFTS,  it 
is  then  important  to  understand  how  the  new  system  will  accomplish  the  unique 
operational  requirements  of  stakeholders.  By  taking  a  higher,  overarching  view  of  the 
system  and  then  further  breaking  down  activities  that  will  be  performed,  the  systems 
engineer  can  identify  the  roles  that  can  be  assigned  to  units  and  supervised  by  cognizant 
commands. 

Described  in  detail  later  in  this  report,  the  primary  way  to  demonstrate  operational 
activity  relationships  in  DOD  programs  is  to  utilize  DoDAF  diagrams.  One  of  these 
diagrams,  the  Operational  Activity  Decomposition  Tree  (OV-5a)  will  show  the  iterative 
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nature  of  operational  activities  that  accomplish  the  functions  listed  previously  in  this 
chapter.  Based  on  the  OV-5a,  Figure  25  depicts  the  relationship  between  the  WFTS  and 
the  activities  that  need  to  be  performed  by  the  system. 


Figure  25.  Overall  WFTS  Operational  Activities 


1.  Support  Training 

To  support  training  on  a  webfires  network,  additional  operational  activities  will  be 
accomplished  as  shown  in  Figure  26. 


Figure  26.  Support  Training  Operational  Activity  Hierarchy 
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a.  Collect  Intelligence  on  Enemy 

Within  the  purview  of  a  webfires  network,  warfighters  must  know  what  to  expect 
from  adversary  units.  The  intelligence  inputs  to  the  WFTS  allow  for  a  simulated  near¬ 
peer  threat  to  display  real-time  tactics  and  capabilities  for  more  realistic  learning  and 
contributing  to  a  high-velocity  learning  concept. 

b.  Establish  Training  Objectives 

In  order  to  evaluate  the  training  process  (described  later  in  this  chapter),  the 
objectives  of  the  fleet-wide  usage  of  the  WFTS  must  be  established  and  changed  as 
necessary  to  match  the  commander’s  intent.  This  occurs  at  the  fleet  (geographic)  and  type 
(platform)  command  levels. 

c.  Establish  Scenarios 

At  multiple  command  levels  and  during  each  phase  of  the  OFRP,  scenarios  will 
be  established  to  match  what  their  respective  units  will  expect  to  encounter  in  an  AOR. 
This  occurs  at  the  fleet  (geographic),  CSG/ESG  (strike  group),  unit  (individual  vessel), 
and  multi-unit  (interoperation  between  vessels  exclusive  of  the  strike  group),  and  cross¬ 
domain  (interoperation  encompassing  all  potential  fleet  and  platform)  levels. 

cl.  Create  Doctrine/Tactics/Procedures 

Based  on  feedback  garnered  from  WFTS  events,  modifications  will  be 
implemented  to  simulation  protocols  based  upon  warfighter  actions  and  enemy  tactics  for 
optimization  of  offensive  and  defensive  actions  in  an  operational  webfires  environment. 

2.  Conduct  Training 

In  order  to  conduct  training  to  implement  a  webfires  network,  additional 
operational  activities  will  be  accomplished  as  shown  in  Figure  27. 
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Figure  27.  Conduct  Training  Operational  Activity  Hierarchy 

a.  Facilitate/Create/Modify/Receive  Scenarios 

After  scenarios  have  been  designed  and  implemented,  the  responsibility  to 
facilitate  and  dictate  actions  within  a  scenario  will  exist.  This  occurs  at  much  the  same 
command  levels  as  seen  in  the  creation  activities.  Scenarios  will  be  manipulated, 
transmitted,  and  received  to  match  the  conditions  within  which  the  cognizant  commands’ 
respective  units  can  be  expected  to  act.  This  activity  occurs  at  the  fleet,  CSG/ESG,  unit, 
multi-unit,  and  cross-domain  levels. 

b.  In-port/At-sea/Hybrid  Training 

At  the  heart  of  cross-domain  training  exists  the  capability  to  link  all  individual 

units  and  simulators,  independent  of  geographic  location  or  seaworthiness,  and  conduct 
training  events. 

c.  Produce  Feedback 

The  training  events  will  be  recorded  and  analyzed  by  commands  to  optimize  the 
scenarios  and  drive  necessary  changes  in  TTPs. 

3.  Evaluate  Training 

In  order  to  evaluate  the  effectiveness  of  the  WFTS,  additional  operational 
activities  will  be  accomplished  as  shown  in  Figure  28. 
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Figure  28.  Evaluate  Training  Operational  Activity  Hierarchy 


a.  Evaluate  and  Certify  Fleet/Strike  Groups/Units 

Prior  to  and  when  established  in  the  deployment  and  advanced  phase  of  the 
OFRP,  commands  must  be  able  to  meet  their  numbered-fleet  commander’s  intent.  The 
WFTS  will  establish  the  opportunity  for  shore-based  leaders  and  fleet  commanders  to 
evaluate  feedback  data  from  training  scenarios. 

b.  Evaluate  Doctrine/Tactics/Procedures 

As  the  database  of  feedback  grows,  intelligence  and  tactical  development 
organizations  will  evaluate  warfighter  actions  within  training  scenarios  to  determine 
whether  a  more  effective  action  would  produce  more  favorable  offensive  or  defensive 
outcomes  for  a  given  set  of  conditions. 

c.  Evaluate  Type  Training 

Operational  and  tactical  leaders  will  have  the  ability  to  evaluate  the  overall 
effectiveness  of  the  training  provided  to  various  types  of  vessels. 
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IX.  ANALYSIS  OF  ALTERNATIVES 


This  chapter  corresponds  to  the  final  major  phase  of  the  project.  These  are  the 
steps  where  a  specific  solution  begins  to  emerge.  Analysis  of  alternatives  is  a  process  in 
which  multiple  design  options,  or  solutions,  are  developed  and  compared  against  one 
another  to  determine  the  best  solution.  The  team  started  this  process  using  a  creativity 
tool  called  a  morphological  box  to  help  develop  alternative  solutions.  Next,  the  team 
developed  the  criteria  against  which  the  design  alternatives  would  be  compared  to 
determine  the  best  solutions. 

These  design  criteria  came  from  the  Critical  Operating  Issues  (COI),  and  the 
Measures  of  Effectiveness  (MOE)  used  to  measure  how  well  a  design  meets  the 
requirements.  Once  the  alternatives  and  grading  criteria  were  developed,  the  next  step 
was  to  evaluate  how  well  each  alternative  meets  the  specified  criteria  and  assign  values 
for  comparison.  For  this  project,  the  team  determined  that  not  all  of  the  criteria  should  be 
equally  weighted.  Swing  weights  were  used  to  determine  which  MOEs  should  be 
considered  of  higher  importance  than  others.  The  assigned  values  were  multiplied  by 
their  associated  swing  weights  to  determine  an  overall  measure  of  effectiveness  (OMOE) 
for  each  design  alternative. 

A.  MORPHOLOGICAL  BOX 

The  design  of  any  system  requires  choosing  the  right  components  to  provide  the 
required  functionality.  The  use  of  a  morphological  box  overcomes  the  limitations  of 
normal  quantitative  methods  of  analysis.  Normal  quantitative  methods,  including 
modeling  and  simulation,  fail  to  capture  the  non-quantifiable  attributes  of  the  factors 
involved  (Richey  2017).  The  morphological  box  approach  captures  the  complexity  of  a 
design  without  the  need  for  a  rigorous  mathematical  approach. 

The  morphological  box  approach  helps  us  choose  design  alternatives  that  meet 
our  high-level  functions.  Underneath  each  high-level  function  is  a  list  of  component 
alternatives  that  are  composed  of  similar  components  designed  to  meet  the  higher  level 
function.  Design  alternatives  are  built  by  selecting  a  number  of  component  alternatives 

85 


from  each  high-level  function  category.  All  of  the  selected  components  comprise  the 
design  alternative.  Each  design  alternative  must  have,  at  a  minimum,  one  component  to 
satisfy  each  of  the  higher  level  functions. 

Our  design  alternatives  represent  the  basic  level  componentry  required  to  build 
the  system.  Each  of  the  design  alternatives  was  chosen  using  a  training  vignette  described 
further  in  this  chapter.  The  alternative  component  list  was  chosen  for  each  function  based 
on  our  best  estimate  of  2030  technology  levels  and  feasibility  based  on  recent  military 
technology  history. 

To  provide  simulations,  we  chose  three  alternatives. 

•  Artificial  Intelligence  would  provide  the  simulation  a  reactive  response  to 
user  inputs  based  on  concepts  derived  from  machine  learning.  The  AI 
would  study  the  current  battlefield  simulation  and  make  intelligent  enemy 
decisions  in  order  to  provide  the  best  simulated  response.  Ideally,  this 
machine  learning  would  be  programmed  to  react  according  to  tactics 
typically  employed  by  a  specified  enemy. 

•  Manual  control  of  the  simulation  would  place  SMEs  in  control  of  the 
opposition  forces.  Enemy  decisions  made  in  the  simulation  would  need 
manual  input  from  the  SMEs  for  the  simulation  to  carry  out. 

•  Pre-Programmed  is  a  form  of  simulation  in  which  a  SME  would  write 
the  simulation  events  and  timing  of  those  events  from  an  enemy 
perspective.  The  SMEs  would  provide  this  simulation  script  for  units  to 
have  available  and  utilize  at  a  later  time.  Enemy  actions  would  be  fixed 
and  predictable  after  multiple  simulation  runs. 

Communication  between  the  different  training  nodes  was  determined  by  looking 
at  four  different  communication  methods. 

•  Hardwire  communications  would  include  fiber  optics,  DSL,  and  T- 
carriers.  These  components  would  physically  link  shore -based  facilities 
with  either  additional  facilities  or  pier-side  ships.  The  components  are  not 
prone  to  interference  and  have  a  relatively  low  cost.  Hardwire  has  the 
greatest  bandwidth  but  is  limited  to  stationary  connections. 

•  Over  the  Horizon  (OTH)  communications  would  include  high  frequency 
radio  communications.  The  ability  to  greatly  extend  the  network  out  to  sea 
is  extremely  beneficial.  Using  the  properties  of  the  atmosphere,  the  signal 
can  bounce  between  the  surface  and  the  ionosphere  to  well  beyond  the 
range  of  traditional  line-of-sight  communications.  The  bandwidth  is 
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somewhat  limited  and  the  hazard  of  transmitting  near  personnel  is 
significant. 

•  Line-of-Sight  (LOS)  communications  could  include  ultra-high  frequency 
(UHF),  very-high  frequency  (VHF),  satellite  communications,  Link  16, 
Link  11,  and  Link  4.  The  properties  of  these  communications  allow  for 
higher  bandwidths  at  reduced  ranges.  Ranges  can  be  extended  with 
repeaters  placed  either  along  the  surface  or  at  higher  altitudes.  The 
limitation  is  that  both  the  transmitting/receiving  antennas  must  physically 
see  each  other.  The  waveform  does  not  allow  for  atmospheric  bouncing 
and  is  more  susceptible  to  degradation  from  weather  phenomena. 

•  Satellite  Communications  technically  use  LOS  frequencies,  but  for 
purposes  of  this  project  have  been  distinguished  from  other  non-satellite 
LOS  communication  methods.  Satellite  LOS  communications  allow  for 
much  greater  separation  of  units  as  curvature  of  the  Earth  is  much  less  of  a 
factor  than  it  is  for  LOS  communications  that  do  not  utilize  satellite  relays. 

Providing  the  simulation  to  the  user  could  be  accomplished  using  three  different 
methods. 

•  Non-Console  hardware  could  include  laptops,  handheld  computers,  or 
other  electronics.  The  hardware  is  not  designed  to  represent  the  consoles 
or  equipment  found  in  the  CSG,  but  represent  one  or  more  features  that 
would  be  found  within  a  CSG.  For  example,  a  laptop  could  run  a  program 
designed  to  simulate  the  radar  console  found  on  a  destroyer.  The  single 
user  interface  would  provide  additional  time  to  leam  simple  tasks  to 
operate  the  webfires  hardware. 

•  Simulated  Console  hardware  could  include  aviation  simulators,  ship 
combat  system  simulators,  and  submarine  combat  system  simulators.  The 
hardware  would  best  represent  the  actual  hardware  used  in  the  CSG/ESG 
with  inputs  modeled  by  computer  simulations. 

•  Actual  Console  hardware  includes  what  the  user  would  actually  use  in  the 
CSG/ESG  environment.  Actual  equipment  provides  the  greatest  level  of 
training  fidelity  and  provides  the  user  the  greatest  learning  environment. 

Controlling  and  evaluating  the  simulation  could  be  accomplished  using  three 
methods. 

•  Central  Control  concept  involves  a  training  headquarters  that  provides 
both  the  training  scenario  and  tools  to  evaluate  the  simulation  in  real  time. 
For  example,  Navy  Training  Groups  are  shore-based  facilities  that 
broadcast  a  computer  simulation  to  actual  units  located  in  exercise  areas. 
These  simulations  provide  the  data  for  actual  units  to  run  exercises 
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without  the  need  for  actual  red  forces.  The  simulation  is  monitored  for 
performance  at  the  shore-based  facility. 

•  Local  Control  concept  involves  a  smaller  SME  team  than  a  central 
control  facility  would  have  available  to  it.  The  vision  is  that  a  local  control 
center  could  be  located  on  the  flagship  within  the  CSG/ESG  for  exercises 
out  to  sea,  or  could  be  a  shore  facility  located  in  the  fleet  concentration 
areas  to  handle  controlling  and  evaluating  the  training  event.  The  SME 
team  at  the  local  control  center  will  provide  all  control,  including  event 
sequence  and  reaction  to  user  decisions.  This  is  intended  to  be  similar  to 
central  control,  but  on  a  smaller  scale,  while  adding  the  capability  to 
establish  a  local  control  center  for  strike  groups  that  are  far  out  to  sea. 

•  Unit  Control  concept  involves  non-SME  members  running  training 
events  at  the  unit  level.  For  example,  if  two  helicopters  wished  to  conduct 
unit-level  training  at  sea  they  could  control  their  own  training  event.  For  a 
surface  ship,  this  control  method  would  be  very  similar  to  using  the  Battle 
Force  Tactical  Trainer  (BFTT)  to  perform  training  exercises.  For  this 
project,  unit  control  does  not  mean  that  one  of  those  units  must  be  in 
control  of  the  simulation,  but  rather  it  means  that  units  have  the  capability 
to  control  the  simulation  if  so  desired.  Units  capable  of  controlling 
simulations  at  the  unit  level  could  still  take  part  in  training  exercises  where 
control  over  the  simulation  rests  with  a  central  station. 

How  the  data  is  shared  between  the  nodes  of  the  network  can  be  modeled  using 
three  network  topologies. 

•  Single  Star  Networks  rely  on  a  single  node  to  transmit  and  receive  data 
between  the  other  training  nodes.  An  example  of  this  network  topology 
would  be  training  group  centers.  The  data  is  sent  out  and  received  by  one 
node  and  rebroadcasted  to  the  CSG/ESG. 

•  Multiple  Star  Networks  are  similar  to  single  star  networks  but  include 
links  that  group  single  star  networks  into  multiple  star  networks.  The 
additional  capability  provides  at-sea  and  shore  units  to  operate  on  the 
same  network. 

•  Mesh  Networks  would  allow  any  unit  to  directly  communicate  with  any 
other  unit  in  the  network.  With  the  mesh  network,  each  unit  has  its  own 
capability  to  communicate  with  other  units  in  the  WFTS. 

Storing  the  training  and  feedback  data  is  possible  using  three  methods. 

•  Centralized  data  storage  would  occur  at  off-site  data  storage  locations. 
Similar  to  cloud  storage,  the  data  is  accessible  anywhere  on  the  network 
and  managed  by  third-party  support. 
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•  Unit  data  storage  could  include  a  server  located  on  each  unit  within  the 
CSG/ESG  that  captures  the  data  from  the  exercises  in  which  that  unit 
participates.  This  data  could  then  be  uploaded  to  a  centralized  network 
without  the  need  for  physical  transportation  of  portable  media  devices. 

•  Portable  Media  could  include  CDs,  external  HDDs,  or  USB  memory. 
This  would  be  applicable  to  unit-level  training  where  network  connectivity 
may  not  be  feasible. 

The  alternative  methods  to  accomplish  the  major  architecture  functions  were 
placed  into  the  morphological  box  as  shown  in  Table  9. 


Table  9.  Morphological  Box 


Functions 

Provide 

Simulation 

Communicate 

Stimulate 

Sensors/Units 

Control 

Simulation 

Interface 

With 

Network 

Store  Feedback 
Data 

ARTIFICIAL 

INTEL 

HARDWIRE 

NON¬ 

CONSOLE 

CENTRAL 

CONTROL 

SINGLE 

STAR 

CENTRALIZED 

MANUAL 

OTH 

SIMULATED 

CONSOLE 

LOCAL 

CONTROL 

MULTIPLE 

STAR 

UNIT 

PRE¬ 

PROGRAMMED 

LOS 

ACTUAL 

CONSOLE 

UNIT  CONTROL 

MESH 

PORTABLE 

MEDIA 

SAT  COMMS 

The  team  has  chosen  all  of  the  design  alternatives  for  evaluation  from  this 
morphological  box.  Design  alternatives  are  chosen  by  selecting  one  or  more  of  the 
options  under  each  of  the  six  major  system  functions. 

B.  DESIGN  ALTERNATIVES 

From  the  morphological  box,  the  team  chose  several  design  alternatives  intended 
to  showcase  various  aspects  of  the  WFTS.  Ultimately,  the  team  chose  to  study  a  total  of 
nine  different  design  alternatives.  Each  of  these  design  alternatives  has  been  numbered  in 
order  of  assessed  training  value,  where  option  one  had  the  highest  overall  training  value 
and  option  nine  had  the  lowest  overall  training  value. 

1.  Fully  capable  system  addresses  all  major  capability  gaps  identified. 

2.  Strike  group  out  to  sea  integrated  with  a  shore -based  simulator  network. 
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3. 


A  ship  out  to  sea  integrated  with  a  ship  in  port. 

4.  A  squadron  of  similar  units  integrating  for  training  out  to  sea. 

5.  Ships  in  port  integrating  with  a  shore  based  simulator. 

6.  A  strike  group  conducting  sustainment  training  at  sea. 

7.  Fleet  synthetic  training  exercise  integrating  in  port  or  at  sea  units  during 
the  integrated  phase. 

8.  Low-fidelity  trainer  integrating  units  at  sea  and  in  port. 

9.  Single  unit  in  port  being  fed  a  scenario  from  a  local  training  center. 

Each  of  these  options  is  discussed  in  greater  detail  in  the  following  sections. 

1.  Design  Alternative  One 

Design  Alternative  One  (DAI)  was  designed  to  be  the  most  capable  WFTS, 
integrating  both  in-port  and  at-sea  operational  units  with  simulators  to  perform  training  in 
all  three  phases  of  the  OFRP.  This  option  was  designed  to  be  capable  of  performing  the 
training  scenarios  of  all  of  the  other  design  alternatives  combined.  A  decision  maker 
would  choose  this  option  when  an  unlimited  budget  is  available.  Figure  29  represents  the 
networking  and  interfacing  capabilities  expected  from  DAI. 
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Images  from  businessinsider.com,  wikipedia.org,  huntingtoningalls.com,  nationstates.net, 
suwalls.com,  sandiegouniontribune.com,  ndtv.com,  and  boeing.com. 

Figure  29.  Design  Alternative  One  Network  Interface  Diagram 


The  morphological  box  for  DAI  is  shown  in  Table  10.  The  cells  highlighted  in 
red  and  bolded  are  the  options  selected  for  DAI. 


Table  10.  Design  Alternative  One  Functions 


Functions 

Provide 

Simulation 

Communicate 

Stimulate 

Sensors/Units 

Control 

Simulation 

Interface 

With 

Network 

Store  Feedback 
Data 

ARTIFICIAL 

INTEL 

HARDWIRE 

NON¬ 

CONSOLE 

CENTRAL 

CONTROL 

SINGLE 

STAR 

CENTRALIZED 

MANUAL 

OTH 

SIMULATED 

CONSOLE 

LOCAL  CONTROL 

MULTIPLE 

STAR 

UNIT 

PRE¬ 

PROGRAMMED 

LOS 

ACTUAL 

CONSOLE 

UNIT  CONTROL 

MESH 

PORTABLE 

MEDIA 

SAT  COMMS 

The  AI  option  provides  high  fidelity  simulations  that  can  be  repeated  frequently 


during  the  basic  and  sustainment  phases.  The  manual  simulations,  great  for  the  integrated 
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training  phase,  allow  for  the  highest  fidelity  training  exercises  at  the  hands  of  SMEs,  but 
with  fewer  repetitions  due  to  the  resources  involved  in  such  simulations.  The 
combination  of  using  both  AI  and  manually  controlled  simulations  can  provide  very  high 
fidelity  simulations  that  can  be  conducted  with  optimal  repetition.  By  including  the 
option  for  all  four  communications  methods,  we  can  use  each  method  where  appropriate 
to  allow  for  full  integration  of  both  in-port  and  at-sea  units  with  shore-based  simulators. 

Units  would  be  conducting  webfires  training  using  actual  combat  systems,  while 
simulated  combat  systems  (high  fidelity  simulators)  would  be  used  to  conduct  webfires 
training  at  shore -based  facilities.  When  each  unit  has  the  capability  to  control  the 
simulation,  the  units  do  not  have  to  rely  upon  the  availability  of  a  central  or  local  control 
station  to  conduct  training  exercises.  Combined  with  the  mesh  network  architecture, 
where  any  unit  or  simulator  can  establish  a  connection  with  any  other  unit  or  simulator, 
any  two  units  available  for  training  can  link  up  and  conduct  training  simulations  together. 
For  DAI,  the  option  was  chosen  to  store  feedback  data  on  a  centralized  server.  This 
allows  faster  and  greater  access  to  training  data  across  the  fleet  as  each  unit  can  review  or 
study  exercises  from  other  units.  Units  can  also  download  or  stream  simulations  from  the 
standardized,  central  database. 

2.  Design  Alternative  Two 

DA2  was  chosen  to  meet  the  requirements  for  conducting  strike  group  training 
exercises  out  to  sea  by  integrating  with  simulators  in  port.  An  example  of  when  this 
alternative  might  be  desirable  is  during  the  beginning  of  the  integrated  phase,  when  the 
strike  group  ships  go  out  to  sea,  but  the  units  of  the  air  wing  will  participate  in  the 
exercise  from  a  shore  training  facility.  When  the  strike  group  is  fully  integrated,  such  as 
during  the  later  stages  of  the  integration  phase  or  even  the  sustainment  phase,  the 
simulator  facilities  on  shore  might  consist  purely  of  opposition  forces.  Figure  30 
represents  the  networking  and  interfacing  capabilities  expected  from  DA2. 
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Images  from  businessinsider.com,  wikipedia.org,  huntingtoningalls.com,  nationstates.net, 
suwalls.com,  ndtv.com,  and  boeing.com. 

Figure  30.  Design  Alternative  Two  Network  Interface  Diagram 


The  morphological  box  for  DA2  is  shown  in  Table  11.  The  cells  highlighted  in 
red  and  bolded  are  the  options  selected  for  DA2. 


Table  11.  Design  Alternative  Two  Functions 


Functions 

Provide 

Simulation 

Communicate 

Stimulate 

Sensors/Units 

Control 

Simulation 

Interface 

With 

Network 

Store  Feedback 
Data 

ARTIFICIAL 

INTEL 

HARDWIRE 

NON¬ 

CONSOLE 

CENTRAL 

CONTROL 

SINGLE 

STAR 

CENTRALIZED 

MANUAL 

OTH 

SIMULATED 

CONSOLE 

LOCAL  CONTROL 

MULTIPLE 

STAR 

UNIT 

PRE¬ 

PROGRAMMED 

LOS 

ACTUAL 

CONSOLE 

UNIT  CONTROL 

MESH 

PORTABLE 

MEDIA 

SAT  COMMS 

As  in  DAI,  the  combination  of  manual  and  pre-programmed  simulations  allows 
for  high  fidelity  and  high  repetition.  By  using  preprogrammed  enemy  actions  during 
simulations  instead  of  enemy  actions  simulated  with  AI,  we  anticipate  a  reduced 
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effectiveness.  However,  with  the  option  to  communicate  via  hardwire,  LOS,  and  satellite 
communications,  the  major  communication  methods  for  transferring  high  data  volumes 
either  in  port  or  at  sea  are  maintained.  This  system  maintains  full  integration  capability 
between  units  and  simulators. 

The  use  of  actual  and  simulated  combat  systems  maintains  a  high  degree  of 
fidelity.  DA2  utilizes  a  central  control  of  the  simulation,  relying  on  a  shore -based  central 
control  facility  to  push  the  simulation  to  the  strike  group  via  satellite  data  networks.  The 
multiple  star  network  option  allows  for  multiple  shore-based  simulators  to  form  the  first 
star  network  with  the  central  control  station,  which  can  then  transfer  the  simulation  data 
to  the  strike  group  flagship.  The  flagship  would  then  act  as  the  hub  for  a  second  star 
network  made  up  of  the  strike  group  units  at  sea.  Data  could  be  recorded  and  stored  at  a 
centralized  facility  on  shore. 

3.  Design  Alternative  Three 

DA3  focuses  on  the  elements  needed  to  integrate  units  at  sea  to  conduct  simulated 
training  exercises  with  units  in  port.  This  design  alternative  came  about  because  it  is  not 
always  possible  to  get  all  of  the  desired  participants  either  at  sea  together  or  in  port 
together  on  a  regular  basis.  Sometimes  equipment  casualties  and  the  need  for  other 
training  events  often  dictate  in  port  and  at  sea  schedules.  That  concern  goes  away  with 
this  alternative  as  it  allows  for  integration  between  at-sea  and  in-port  units.  Figure  31 
represents  the  networking  and  interfacing  capabilities  expected  from  DA3. 
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Images  from  businessinsider.com,  wikipedia.org,  huntingtoningalls.com, 
nationstates.net,  suwalls.com,  sandiegouniontribune.com,  ndtv.com,  and 
boeing.com. 


Figure  31.  Design  Alternative  Three  Network  Interface  Diagram 


The  morphological  box  for  DA3  is  shown  in  Table  12.  The  cells  highlighted  in 
red  and  bolded  are  the  options  selected  for  DA3. 


Table  12.  Design  Alternative  Three  Functions 
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Simulation 
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Simulation 
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CONTROL 
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STAR 
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LOCAL  CONTROL 
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STAR 
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LOS 

ACTUAL 

CONSOLE 

UNIT  CONTROL 

MESH 

PORTABLE 

MEDIA 

SAT  COMMS 
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The  combination  of  manual  and  preprogrammed  simulations  allows  for  high 
fidelity  and  frequent  repetition.  A  shore -based  central  control  station  would  provide  the 
hub  of  a  star  network.  Hardwire  communications  can  be  used  to  link  units  in  port  to  the 
hub,  while  units  at  sea  would  be  connected  to  the  hub  via  satellite  communication  links. 
In  the  event  an  in-port  unit’s  combat  system  is  down,  that  unit  can  relocate  its  watch 
teams  to  a  nearby  simulator  facility  located  at  its  fleet  concentration  area. 

4.  Design  Alternative  Four 

DA4  is  designed  to  allow  at  sea  training  of  a  squadron  of  units  such  as  a  Surface 
Action  Group  or  an  air  wing,  but  not  a  complete  strike  group.  The  intention  of  this  design 
alternative  is  to  implement  webfires  training  into  type  group  (TYCOM)  training  exercises 
that  take  place  before  integrating  with  the  rest  of  the  strike  group.  Figure  32  represents 
the  networking  and  interfacing  capabilities  expected  from  DA4.  It  is  not  necessarily 
limited  to  the  destroyer  squadron  SAG  portrayed  in  the  figure.  The  type  group  could  be 
made  up  of  a  submarine  squadron,  an  air  wing,  or  any  other  webfires-capable  squadron. 


Images  from  huntingtoningalls.com. 


Figure  32.  Design  Alternative  Four  Network  Interface  Diagram 


The  morphological  box  for  DA4  is  shown  in  Table  13.  The  cells  highlighted  in 
red  and  bolded  are  the  options  selected  for  DA4. 
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Table  13.  Design  Alternative  Four  Functions 


Functions 

Provide 

Simulation 

Communicate 

Stimulate 

Sensors/Units 

Control 

Simulation 

Interface 

With 

Network 

Store  Feedback 
Data 

ARTIFICIAL 

INTEL 

HARDWIRE 

NON¬ 

CONSOLE 

CENTRAL 

CONTROL 

SINGLE 

STAR 

CENTRALIZED 

MANUAL 

OTH 

SIMULATED 

CONSOLE 

LOCAL  CONTROL 

MULTIPLE 

STAR 

UNIT 

PRE¬ 

PROGRAMMED 

LOS 

ACTUAL 

CONSOLE 

UNIT  CONTROL 

MESH 

PORTABLE 

MEDIA 

SAT  COMMS 

The  combination  of  manual  and  preprogrammed  simulations  allows  for  high 
fidelity  and  optimal  repetition.  The  difference  for  this  alternative  is  that  the  manual 
control  would  most  likely  be  carried  out  by  one  of  the  units  designated  as  the  unit 
controlling  the  simulation.  LOS  and  satellite  communications  provides  ample  data  rates 
between  units  integrated  at  sea.  Any  decrease  in  fidelity  from  not  having  the  SMEs 
associated  with  a  central  control  station  controlling  opposition  forces  will  be  offset  by  the 
increase  in  fidelity  from  the  simulations  taking  place  on  the  actual  webfires  combat 
systems  via  combat  system  simulators.  Without  a  connection  to  a  central  or  local  hub  to 
control  the  simulation,  units  participating  in  this  type  of  at-sea  training  must  have  the 
capability  for  unit  control.  Units  would  be  directly  integrated  with  each  other  using  a 
mesh  network,  with  a  unit  designated  as  the  control  unit  for  that  simulation. 

5.  Design  Alternative  Five 

DA5  allows  multiple  ships  in  port  to  integrate  with  a  shore -based  simulator 
facility.  This  is  similar  to  the  current  FST  system,  but  with  the  notable  addition  of  also 
running  preprogrammed  scenarios.  This  design  alternative  could  be  used  for  an  entire 
strike  group  in  port  participating  with  a  shore-based  simulation  facility,  or  this  design 
alternative  could  be  used  for  only  one  ship  in  port  participating  with  a  shore-based 
simulation  facility.  Figure  33  represents  the  networking  and  interfacing  capabilities 
expected  from  DA5. 
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Images  from  sandiegouniontribune.com,  ndtv.com,  and  boeing.com. 

Figure  33.  Design  Alternative  Five  Network  Interface  Diagram 


The  morphological  box  for  DA5  is  shown  in  Table  14.  The  cells  highlighted  in 
red  and  bolded  are  the  options  selected  for  DA5. 


Table  14.  Design  Alternative  Five  Functions 
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CONTROL 

SINGLE 

STAR 
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LOCAL  CONTROL 
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STAR 
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PRE¬ 
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ACTUAL 
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UNIT  CONTROL 

MESH 

PORTABLE 

MEDIA 

SAT  COMMS 

The  combination  of  manual  and  preprogrammed  simulations  allows  for  high 
fidelity  and  optimal  repetition.  Since  all  units  are  stationary,  either  on  land  or  in  port, 
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hardwire  will  provide  a  cost-effective  solution  for  communications  at  high  data  rates. 
Simulated  combat  system  consoles  and  actual  combat  systems  consoles  were  selected  to 
represent  the  actual  combat  systems  on  the  ship  as  well  as  the  simulator  facility  on  shore. 
The  redundant  communications  paths  of  a  mesh  network  are  not  necessary  for  this 
hardwired  training  network,  so  a  single  star  network  should  suffice.  Units  can  store  their 
own  data  for  later  evaluation. 

6.  Design  Alternative  Six 

The  vision  for  DA6  was  a  strike  group  conducting  sustainment  training  at  sea,  far 
from  shore-based  simulator  facilities.  The  idea  here  is  the  strike  group  might  be  making  a 
long  ocean  transit  as  part  of  a  deployment  or  might  just  be  out  to  sea  together  for 
sustainment  training  as  a  strike  group  after  returning  from  a  deployment.  One  goal  for 
this  design  alternative  was  minimal  reliance  upon  shore  facilities  while  conducting 
training.  Training  associated  with  DA6  is  expected  to  be  the  closest  design  alternative  to 
actual  webfires  employment.  Figure  34  represents  the  networking  and  interfacing 
capabilities  expected  from  DA6. 
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Images  from  businessinsider.com,  wikipedia.org,  huntingtoningalls.com,  nationstates.net, 
and  suwalls.com. 


Figure  34.  Design  Alternative  Six  Network  Interface  Diagram 
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The  morphological  box  for  DA6  is  shown  in  Table  15.  The  cells  highlighted  in 
red  and  bolded  are  the  options  selected  for  DA6. 


Table  15.  Design  Alternative  Six  Functions 


Functions 

Provide 

Simulation 

Communicate 

Stimulate 

Sensors/Units 

Control 

Simulation 

Interface 

With 

Network 

Store  Feedback 
Data 

ARTIFICIAL 

INTEL 

HARDWIRE 

NON¬ 

CONSOLE 

CENTRAL 

CONTROL 

SINGLE 

STAR 

CENTRALIZED 

MANUAL 

OTH 

SIMULATED 

CONSOLE 

LOCAL 

CONTROL 

MULTIPLE 

STAR 

UNIT 

PRE¬ 

PROGRAMMED 

LOS 

ACTUAL 

CONSOLE 

UNIT  CONTROL 

MESH 

PORTABLE 

MEDIA 

SAT  COMMS 

The  combination  of  manual  and  preprogrammed  simulations  allows  for  high 
fidelity  and  frequent  repetition.  Here  the  SMEs  controlling  the  exercise  would  be  located 
on  the  flagship  of  the  strike  group.  These  could  be  a  few  civilian  contractors  whose 
expertise  is  in  the  enemy’s  tactics,  or  they  might  be  members  of  the  U.S.  Navy’s 
intelligence  community,  or  Weapons  and  Tactics  Instructors  who  might  have  expertise 
comparable  to  the  SMEs  found  at  shore  training  facilities,  such  as  the  tactical  training 
groups,  but  are  still  recognized  as  experts  in  their  warfare  areas.  Because  this  training 
scenario  is  isolated  to  the  strike  group  out  to  sea,  LOS  was  chosen  exclusively. 

Satellite  communications  might  not  be  available  in  the  environment  where  the 
strike  group  is  expected  to  be  employing  webfires,  and  so  this  WFTS  design  does  not  use 
satellites  to  communicate.  Actual  combat  consoles  were  chosen  because  each  unit  in  the 
strike  group  will  be  conducting  the  training  simulation  using  their  actual  combat  units. 
The  difference  would  be  that  the  consoles  would  be  in  a  training  mode  that  allows  them 
to  display  simulated  sensor  data.  Simulation  would  come  from  a  local  control  center 
residing  within  the  strike  group,  likely  the  CVN  or  the  LHD/LHA.  Units  would  interface 
using  a  WFTS  mesh  network,  which  is  the  network  architecture  that  the  webfires  system 
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would  be  expected  to  employ.  Each  unit  in  the  strike  group  would  store  its  own 
performance  data  locally. 

7.  Design  Alternative  Seven 

DA7  aims  to  represent  a  blend  of  the  current  FST  architecture  and  the  Composite 
Training  Unit  Exercise  (COMPTUEX)  architecture.  The  major  difference  between  this 
design  alternative  and  FST  or  COMPTUEX,  is  that  this  design  allows  for  the  in-port  units 
to  participate  alongside  at-sea  units.  Figure  35  represents  the  networking  and  interfacing 
capabilities  expected  from  DA7. 


Images  frombusinessinsider.com,  wikipedia.org,  huntingtoningalls.com,  nationstates.net, 
suwalls.com,  sandiegouniontribune.com,  and  boeing.com. 

Figure  35.  Design  Alternative  Seven  Network  Interface  Diagram 


The  morphological  box  for  DA7  is  shown  in  Table  16.  The  cells  highlighted  in 
red  and  bolded  are  the  options  selected  for  DA7. 
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Table  16.  Design  Alternative  Seven  Functions 


Functions 

Provide 

Simulation 

Communicate 

Stimulate 

Sensors/Units 

Control 

Simulation 

Interface 

With 

Network 

Store  Feedback 
Data 

ARTIFICIAL 

INTEL 

HARDWIRE 

NON¬ 

CONSOLE 

CENTRAL 

CONTROL 

SINGLE 

STAR 

CENTRALIZED 

MANUAL 

OTH 

SIMULATED 

CONSOLE 

LOCAL  CONTROL 

MULTIPLE 

STAR 

UNIT 

PRE¬ 

PROGRAMMED 

LOS 

ACTUAL 

CONSOLE 

UNIT  CONTROL 

MESH 

PORTABLE 

MEDIA 

SAT  COMMS 

For  this  design  alternative  all  simulations  are  provided  with  manual  control  of  the 
opposition  forces  by  trained  SMEs  located  at  one  of  the  tactical  training  groups.  Units  at 
sea  would  communicate  simulation  data  using  LOS  communications,  while  units  in  port 
would  use  hardwire  communications.  To  network  the  in-port  units  with  the  units  at  sea, 
satellite  communications  would  be  used.  This  communication  would  occur  using  a  single 
star  network  with  a  central  control  station  hub  to  push  the  simulations  out  to  the 
participants’  actual  combat  systems  or  simulator  combat  system  consoles  located  at 
shore-based  facilities.  The  central  control  station  would  store  the  data  for  performance 
evaluation. 


8.  Design  Alternative  Eight 

DA8  represents  units  in  port  and  at  sea  participating  in  a  low  fidelity  trainer 
scenario.  This  type  of  training  might  be  valuable  at  the  end  of  the  basic  phase  in 
preparation  for  entering  the  integrated  phase,  or  it  might  be  useful  in  the  sustainment 
phase  to  maintain  proficiency.  Figure  36  represents  the  networking  and  interfacing 
capabilities  expected  from  DA8. 


102 


Images  from  huntingtoningalls.com  and  sandiegouniontribune.com. 

Figure  36.  Design  Alternative  Eight  Network  Interface  Diagram 


The  morphological  box  for  DA8  is  shown  in  Table  17.  The  cells  highlighted  in 
red  and  bolded  are  the  options  selected  for  DA8. 


Table  17.  Design  Alternative  Eight  Functions 
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Simulation 
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NON¬ 
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CENTRAL 
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CENTRALIZED 
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LOCAL  CONTROL 
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STAR 
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PROGRAMMED 

LOS 
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CONSOLE 

UNIT  CONTROL 

MESH 

PORTABLE 

MEDIA 

SAT  COMMS 

This  alternative  uses  simple  preprogrammed  simulations  designed  to  maintain 
proficiency  in  entry  level  tactics  and  decisions.  Preprogrammed  simulations  were  chosen 
for  their  ease  of  uploading  and  repetition.  A  non-console  system  was  chosen  to  represent 
a  low  fidelity  trainer  such  as  a  laptop,  where  a  warfighter  can  log  in  when  time  is 
available  and  interface  with  another  participant.  Hardwire  communications  would  be 
used  for  units  on  land,  while  satellite  communications  would  be  used  to  interface  with 
units  at  sea.  At  each  end,  units  would  likely  network  into  local  hubs  that  would  then 
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communicate  with  each  other,  but  control  of  the  simulations  would  reside  with  one  of  the 
participating  units. 

9.  Design  Alternative  Nine 

DA9  represents  a  single  unit  in  port  receiving  a  preprogrammed  scenario  from  a 
local  shore -based  simulation  facility.  This  type  of  scenario  can  be  used  during  any  of  the 
phases,  depending  on  the  preprogrammed  simulation  provided.  During  the  integrated 
phase,  integration  can  be  simulated  by  preprogramming  virtual  participants  into  the 
simulation.  Figure  37  represents  the  networking  and  interfacing  capabilities  expected 
from  DA9. 


Images  from  sandiegouniontribune.com  and  boeing.com. 

Figure  37.  Design  Alternative  Nine  Network  Interface  Diagram 


The  morphological  box  for  DA9  is  shown  in  Table  18.  The  cells  highlighted  in 
red  and  bolded  are  the  options  selected  for  DA9. 


Table  18.  Design  Alternative  Nine  Functions 
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UNIT  CONTROL 
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PORTABLE 

MEDIA 

SAT  COMMS 
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Preprogrammed  simulation  allows  for  frequent  repetition  as  the  scenario  can  be 
run  multiple  times  according  to  the  unit’s  own  schedule.  As  the  unit  is  in  port,  hardwire 
provides  a  cost-effective  means  of  communication  back  to  a  simulator  facility.  The  unit 
performs  the  exercises  using  its  own  actual  combat  systems  to  maintain  fidelity.  A  local 
control  facility  would  transmit  the  simulation  to  the  unit  via  a  star  network.  This  allows 
multiple  units  to  utilize  the  same  local  control  center  to  simultaneously  conduct  different 
training  scenarios.  Units  would  store  their  own  performance  data  to  have  on  hand  for 
evaluation  upon  completion  of  the  training. 

C.  TRADE-OFF  BETWEEN  COMPONENTS 

The  team  identified  six  high-level  system  functions  of  the  WFTS.  These  six  high- 
level  system  functions  are:  provide  simulation,  communicate,  stimulate  units,  control 
simulation,  interface  with  network,  and  store  data.  Based  on  these  system  functions,  the 
team  identified  three  to  four  methods  to  fulfill  each  function.  After  identifying  the  list  of 
methods,  the  team  conducted  a  trade-off  analysis  of  the  components  to  determine  the 
advantages  and  disadvantages  of  each  method. 

1.  Providing  Simulation 

Artificial  intelligence  has  the  potential  to  mimic  enemy’s  tactics  while  not  relying 
on  the  SMEs  to  manually  run  the  scenarios.  When  the  AI  is  programmed  with  input  from 
the  SME,  the  major  benefit  is  that  that  units  can  now  run  higher  fidelity  preprogrammed 
scenarios  that  do  not  rely  on  the  availability  or  logistical  burdens  that  must  be  considered 
when  running  high  fidelity  scenarios  through  a  central  training  facility,  as  is  the  case 
during  COMPTUEX.  AI  scenarios  provide  frequent  repetition  training  opportunities 
while  maintaining  the  high  fidelity  enemy  actions  seen  with  SME  controlled  systems. 
The  problem  with  AI  systems  is  the  high  cost  and  time  commitment  necessary  for  the  AI 
programming. 

Manually  controlled  simulations  rely  heavily  on  the  knowledge  of  SMEs  to 

ensure  the  fidelity  of  enemy  tactics  employed  and  their  responses  to  friendly  actions.  At 

the  hands  of  SMEs,  manually  controlled  simulation  provides  the  highest  fidelity  enemy 

tactics  that  warfighters  can  train  against.  The  trade-off  for  the  high  fidelity  achieved  in 
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manual  simulations,  though,  is  the  limited  number  of  repetitions  in  conducting  exercises. 
The  resource  requirements  to  ensure  SMEs  are  available  for  every  training  exercise  of 
every  unit  would  be  prohibitive. 

Preprogrammed  simulations  are  low  cost  and  easily  repeatable  so  that  warfighters 
can  make  evaluations  and  adjustments  to  improve  performance  with  each  iteration. 
However,  the  trade  off  with  preprogrammed  simulations  is  that  they  typically  have  low 
tactical  fidelity  and  events  become  predictable  after  several  iterations. 

2.  Communicate 

Hardwire  communications  such  as  fiber  optics  or  Local  Area  Network  (LAN) 
lines  provide  the  highest  data  rates  and  are  inexpensive  to  implement  over  short 
distances.  However,  the  drawback  to  the  great  data  rates  hardwire  can  provide  is  limited 
by  mobility.  Hardwire  communications  do  not  lend  themselves  to  effective  use  between 
ships  at  sea. 

Over-the-Horizon  communications  provide  at-sea  communication  capabilities 
using  High  Lrequency  (HE)  waves  that  can  bounce  off  the  atmosphere  to  travel  great 
distances.  However,  data  rates  associated  with  HE  communications  are  expected  to  be  too 
low  to  transmit  the  amount  of  data  needed  for  webfires  training  scenarios.  Additionally, 
HF  communications  can  pose  a  radiation  hazard  for  personnel  near  the  antennas,  such  as 
may  be  the  case  with  multiple  ships  in  port. 

Line-of-sight  communications  offer  high  data  rates  for  units  that  are  in  direct  sight 
of  one  another.  The  downside  of  LOS  communications  is  that  the  curvature  of  the  Earth 
limits  the  ranges  in  which  LOS  communications  can  be  used  without  the  need  for  relays 
or  very  high  antennas. 

Satellite  communications  are  technically  LOS  communications  using  satellites  as 
relays.  These  communications  offer  similar  data  rates  to  other  LOS  communications,  but 
allow  for  communicating  that  data  over  much  greater  ranges.  The  trade-off  is  that  the 
need  for  satellites  makes  this  option  very  expensive  and  these  satellites  are  not  always 
available  for  training  due  to  competing  priorities. 
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3. 


Stimulate  Units 


Actual  combat  systems  provide  the  highest  fidelity  but  are  the  most  expensive  to 
build  and  maintain.  Actual  combat  systems  typically  come  with  higher  manpower 
demands  as  each  relevant  console  needs  an  operator  to  perform  that  console’s  functions. 
Additionally,  performing  training  on  actual  combat  systems  might  not  be  possible  if  those 
systems  are  down  for  maintenance. 

Simulated  combat  systems  provide  medium  fidelity  and,  depending  on  the 
location,  can  be  utilized  by  multiple  units.  Simulated  combat  systems  can  be  used  as  a 
backup  when  actual  combat  systems  are  unavailable,  but  typically  they  do  not  offer  the 
same  fidelity. 

Non-combat  system  consoles  such  as  a  laptop  or  a  stand-alone  system  are  the 
cheapest  and  offer  the  greatest  potential  for  repetition.  Simulations  on  non-combat 
systems  are  assessed  to  have  the  lowest  fidelity  of  training. 

4.  Control  Simulation 

Both  central  control  and  local  control  are  great  for  unity  of  command,  but  each 
can  become  a  single  point  of  failure  because  of  its  lack  of  redundancy.  By  contrast,  unit 
control  does  not  rely  on  a  central  or  local  control  node;  every  Webfires  capable  unit  can 
control  the  simulation. 

5.  Interface  with  Network 

Both  the  star  network  and  multiple  star  networks  are  the  most  common  topology. 
A  central  hub  controls  and  monitors  all  connected  units.  It  is  relatively  easy  for  the  units 
to  connect  and  disconnect  from  the  network.  The  disadvantage  of  this  type  of  network  is 
its  reliance  on  the  central  hub.  When  the  central  hub  fails,  it  brings  down  the  entire 
network.  By  contrast,  a  mesh  network  is  much  more  robust  and  reliable.  When  one  of  the 
nodes  goes  down,  it  does  not  bring  down  the  entire  network. 
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6. 


Store  Data 


Centralized  storage  contains  all  available  data  and  allows  easy  access  for  all  units. 
However,  due  to  its  lack  of  redundancy  it  can  become  a  single  point  of  failure.  Local 
storage  provides  the  unit  with  easy  access  to  its  own  data  without  relying  on  the  network. 
While  a  portable  medium  is  very  convenient  and  low  cost,  it  takes  a  long  time  to  transfer 
data  to  its  destination.  The  other  disadvantage  of  both  local  storage  and  portable  media  is 
that  they  only  contain  partial  picture  data. 

The  results  of  the  components  trade-off  analysis  are  summarized  in  Appendix  C. 

D.  COST  EFFECTIVE  TRADE-OFF 

As  stated  in  Chapter  II,  cost  effectiveness  is  addressed  from  a  qualitative  rather 
than  quantitative  analysis  here.  The  cost-effective  trade-offs  will  now  be  discussed  in 
greater  detail.  After  an  analysis  of  the  previously  described  components,  we  find  the 
more  capable  systems  tend  to  have  higher  costs  associated  with  them.  This  is  expected;  as 
capabilities  increase,  expected  costs  often  increase,  too.  Nevertheless,  there  are  ways  to 
reduce  costs  throughout  the  process  without  loss  of  capability. 

The  major  capability  gaps  identified  were  a  lack  of  repetition  and  a  lack  of 
integration.  Increasing  repetition  by  conducting  training  at  sea  more  often  would  lead  to 
cost  increases.  Training  simulations,  by  comparison,  can  be  conducted  more  cheaply  and 
quickly  than  getting  underway  or  conducting  flight  operations.  Imagine  a  unit  is  going  to 
conduct  five  training  exercises  at  sea.  Using  training  simulations,  the  unit  might  replace 
two  of  those  at-sea  exercises  with  four  to  six  in-port  training  exercises  in  the  same  time. 
Costs  would  be  reduced  by  not  burning  the  fuel  or  paying  for  port  operations  to  get 
underway  and  return.  Additionally,  the  unit  will  have  now  completed  seven  to  nine 
training  exercises,  three  at  sea  and  four  to  six  simulated,  in  the  same  time  it  had  originally 
planned  to  conduct  only  five  exercises.  Simulation  allows  greater  frequency  of  training  at 
reduced  costs  by  reducing  the  underway  time  needed  for  training. 

By  utilizing  lower  fidelity  preprogrammed  simulations,  the  costs  of  simulation 

could  be  even  further  reduced  in  comparison  with  the  more  expensive  simulations  such  as 

those  using  AI  or  SMEs  in  manual  control.  Using  non-combat  system  consoles  could 
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further  reduce  the  cost  to  provide  training  simulations,  but  again,  at  the  expense  of 
fidelity.  The  major  trade-offs  seem  to  be  between  repetition,  fidelity,  and  costs.  A 
reasonable  trade-off  seems  to  be  to  focus  on  low  cost,  low  fidelity,  and  highly  repetitive 
simulations  earlier  in  the  OFRP.  As  training  progresses,  low  cost  simulations  could  give 
way  to  more  expensive,  higher  fidelity,  less  repeatable  simulations,  and  live  exercises. 

Increasing  the  training  simulation  capacity  and  integration  capability  will  be  a 
large  capital  expense.  Nevertheless,  there  is  potential  for  great  cost  efficiency  if  the  same 
training  proficiency  can  be  obtained  while  decreasing  underway  time  or  flight  hours.  If 
unit  or  mission  loss  can  be  prevented  through  more  effective  warfighting,  the  cost 
efficiency  is  even  greater. 

E.  CRITICAL  OPERATING  ISSUES  AND  MEASURES  OF 

EFFECTIVENESS 

From  the  morphological  box  provided  earlier  in  this  chapter,  the  team  chose 
methods  to  accomplish  each  function  and  to  evaluate  how  well  those  options  meet 
training  objectives.  As  a  first  step,  the  specific  evaluation  criteria  must  be  developed.  The 
team  developed  these  criteria  by  reviewing  the  capability  and  functional  requirements 
and  by  developing  a  list  of  Critical  Operating  Issues  (COI).  Each  COI  was  then  broken 
into  several  Measures  of  Effectiveness  (MOE). 

1.  COI  1  -  How  well  does  the  system  support  training  during  the  OFRP 
cycle? 

MOE  1.1:  System  fit  into  the  Basic  Phase 
MOE  1.2:  System  fit  into  the  Integrated  Phase 
MOE  1.3:  System  fit  into  the  Sustainment  Phase 

2.  COI  2  -  How  well  does  the  system  train  to  a  near-peer  threat? 

MOE  2.1:  Scenario  management 
MOE  2.2:  Understanding  enemy 
MOE  2.3:  Identify  warfighter  decisions 

3.  COI  3  -  How  well  does  the  system  provide  relevant  data  to  support 
evaluation? 
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MOE  3.1:  Automation  of  data  processing 

4.  COI  4  -  How  well  does  the  system  integrate  units  and  simulators? 

MOE  4.1:  Integration  within  units  or  simulators 
MOE  4.2:  Integration  between  units  and  simulators 
MOE  4.3:  Integration  at  sea 
MOE  4.4:  Integration  at  sea  with  in-port  units 
MOE  4.5:  Integration  in  port 

5.  COI  5  -  How  well  does  system  implement  the  principles  of  high-velocity 
learning? 

MOE  5.1:  Fidelity 

MOE  5.2:  Repetition 

MOE  5.3:  Retention 

Descriptions  of  each  COI  and  MOE  are  provided  in  the  following  paragraphs. 

1.  COI  1  -  How  Well  Does  the  System  Support  Training  during  the 
OFRP  Cycle? 

For  this  project,  it  was  important  to  the  team  that  the  webfires  training 
architecture  fits  into  the  existing  greater  navy  training  architecture,  such  as  the  OFRP, 
where  feasible.  Training  takes  place  during  the  OFRP  primarily  in  three  phases:  the  basic, 
integrated,  and  sustainment  phases.  It  was  desirable  that  the  proposed  webfires  training 
system  also  fit  into  these  three  phases  for  ease  of  transition  and  implementation. 

a.  MOE  1.1:  System  Fit  into  the  Basic  Phase 

This  MOE  is  designed  to  evaluate  how  well  the  proposed  webfires  training 
architecture  meets  the  unit-level  training  expectations  laid  out  in  the  Basic  Phase, 
including  both  the  at-sea  and  in-port  portions. 

b.  MOE  1.2:  System  Fit  into  the  Integrated  Phase 

This  MOE  is  designed  to  evaluate  how  well  the  proposed  webfires  training 
architecture  meets  the  training  expectations  laid  out  in  the  Integrated  Phase,  including 
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both  the  at-sea  and  in-port  portions.  This  MOE  is  also  intended  to  capture  how  well  the 
system  can  perform  unit  training  requirements  that  are  periodically  recurring  from  the 
basic  phase. 

c.  MOE  1.3:  System  Fit  into  the  Sustainment  Phase 

This  MOE  is  designed  to  evaluate  how  well  the  proposed  webfires  training 
architecture  meets  the  training  expectations  laid  out  in  the  Sustainment  Phase,  to 
including  both  the  at-sea  and  in-port  portions.  This  MOE  is  also  intended  to  capture  how 
well  the  system  can  perform  both  unit  and  multi-unit  training  requirements  that  are 
periodically  recurring  from  the  basic  and  integrated  phases. 

2.  COI 2  -  How  Well  Does  the  System  Support  Training  to  a  Near-Peer 
Threat? 

This  COI  is  designed  to  assess  how  well  the  system  supports  training  to  a  high 
level,  complex  threat  scenario.  The  ultimate  purpose  of  the  training  architecture  is  to  train 
warfighters  in  the  doctrines  and  tactics  used  to  counter  an  enemy  threat. 

a.  MOE  2.1:  Scenario  Management 

This  MOE  is  designed  to  encompass  an  array  of  performance  measures  that  could 
be  used  to  determine  how  difficult  a  scenario  is  to  manage.  These  factors  would  include 
the  difficulty  in  creating  and  modifying  a  scenario,  the  difficulty  in  scheduling  a  scenario, 
and  the  difficulty  in  bringing  participants  together  to  take  part  in  a  designated  scenario. 

b.  MOE  2.2:  Understanding  Enemy 

This  MOE  is  designed  to  capture  how  well  the  warfighter  can  understand  a  given 
enemy’s  intentions  and  predict  the  near-future  actions  of  that  enemy.  Understanding  an 
enemy’s  likely  course  of  action  is  important  to  countering  that  enemy.  One  goal  of  this 
training  architecture  is  to  ensure  the  enemy  portrayed  in  simulations  is  represented  as 
accurately  as  possible. 
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c.  MOE  2.3:  Identify  Warfighter  Decisions 

This  MOE  is  designed  to  capture  the  actions  and  decisions  of  the  warfighter  and 
analyze  the  impact  of  those  decisions  on  the  simulation.  The  intent  is  to  identify  the 
decisions  made  and,  through  an  analysis  and  feedback  process,  determine  whether  the 
decisions  made  were  the  correct  decisions  in  accordance  with  doctrine  and  training, 
tactics,  and  procedures. 

3.  COI 3  -  How  Well  Does  the  System  Provide  Relevant  Data  to  Support 
Evaluation  and  Feedback? 

An  important  aspect  of  effective  training  is  an  iterative  process  involving  training, 
evaluation,  and  feedback.  After  engaging  with  stakeholders  and  from  the  team’s  own 
fleet  experience,  it  was  determined  that  delays  in  the  evaluation  process  cause  delays  in 
future  training  opportunities.  Additionally,  it  was  determined  that  evaluation  and 
feedback  are  most  effective  when  they  are  provided  in  a  timely  manner  upon  completion 
of  the  training  simulation. 

a.  MOE  3.1:  Automation  of  Data  Processing 

This  MOE  is  designed  to  capture  the  automation  in  processing  that  data  that  may 
be  used  to  evaluate  a  unit  or  warfighter’s  performance  during  a  scenario.  Stakeholder 
interviews  cited  a  several  hour  delay  in  the  evaluation  and  feedback  process  when 
simulation  tapes  need  to  be  reviewed  prior  to  providing  performance  feedback.  If  the 
system  could  be  programmed  to  automate  the  evaluation  process,  it  is  possible  to  evaluate 
at  near  real  time.  Additionally,  performance  feedback  data  could  be  provided  at  near  real 
time.  Reducing  the  delay  in  receiving  feedback  could  reduce  the  delay  before 
commencing  the  next  iteration  of  training. 

4.  COI  4  -  How  Well  Does  the  System  Integrate  Units  and  Simulators? 

Integration  is  one  of  the  largest  gaps  the  team  identified  through  stakeholder 
interactions.  Air,  surface,  and  subsurface  communities  all  have  simulators  to  train  their 
respective  communities,  but  those  simulators  rarely  have  the  capability  to  integrate  with 
other  simulators  of  the  same  community,  let  alone  the  simulators  of  other  communities. 
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The  team  determined  if  integration  is  the  ultimate  goal  of  a  strike  group  employing 
webfires,  then  integration  between  the  communities  must  take  place  as  early  and  often  as 
is  feasible.  Integrating  simulators  and  units  across  all  communities  should  help  achieve 
these  integration  goals. 

a.  MOE  4.1:  Integration  within  Units  or  Simulators 

This  MOE  measures  the  effectiveness  of  the  proposed  system  to  integrate  units  of 
a  strike  group  with  other  units,  or  to  integrate  simulators  with  other  simulators.  It  is  not 
intended  to  measure  a  simulator’s  ability  to  integrate  with  a  unit. 

b.  MOE  4.2:  Integration  between  Units  and  Simulators 

This  MOE  is  designed  to  measure  the  effectiveness  of  a  unit  to  integrate  with  a 
simulator.  All  units  composing  a  strike  group  are  to  be  considered,  as  are  all  simulators 
used  across  the  communities. 

c.  MOE  4.3:  Integration  at  Sea 

This  MOE  measures  how  well  units  integrate  with  each  other  at  sea  for  training 
simulations.  This  considers  units  at  sea  in  coastal  regions  where  they  may  be  stimulated 
from  shore  facility  antennas  as  well  as  units  far  out  to  sea,  such  as  crossing  an  ocean  on 
the  way  to  or  from  deployment. 

d.  MOE  4.4:  Integration  at  Sea  with  In-Port  Units 

This  MOE  captures  how  well  strike  group  units  out  to  sea  can  integrate  with  units 
that  remain  in  port.  It  is  not  always  feasible  to  have  all  units  designated  to  participate  in  a 
particular  training  exercise  together  in  port  or  together  out  to  sea.  If  the  system  can 
integrate  units  at  sea  with  units  in  port,  this  would  alleviate  that  constraint. 

e.  MOE  4.5:  Integration  in  Port 

This  MOE  measures  the  effectiveness  of  the  strike  group  to  conduct  integrated 
training  scenarios  in  port,  similar  to  the  FST  events  conducted  today. 
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5.  COI 5  -  How  Well  Does  the  System  Implement  the  Principles  of  High- 
Velocity  Learning? 

The  weapon  systems  wielded  on  the  battlefield  today  are  more  complex  than  ever 
before  and  so  is  the  training  associated  with  employing  those  weapon  systems.  It  is  of 
vital  importance  to  train  better  and  more  quickly  to  stay  ahead  of  a  potential  adversary. 
This  COI  addresses  how  well  the  proposed  training  system  achieves  the  principles  of 
high-velocity  learning. 

a.  MOE  5.1:  Fidelity 

This  MOE  captures  the  fidelity  of  the  training  taking  place.  It  is  intended  to 
capture  all  aspects  of  fidelity,  including  the  fidelity  of  the  weapons  and  tactics  employed, 
the  fidelity  of  enemy  responses  to  warfighter  actions,  and  the  fidelity  of  the  console  or 
simulator  used  to  provide  the  training. 

b.  MOE  5.2:  Repetition 

This  MOE  captures  the  ease  of  repetition  of  a  proposed  training  architecture. 
During  stakeholder  engagement  and  from  personal  experience,  the  team  identified  a  lack 
of  repetition  when  it  comes  to  training,  particularly  integrated  training  at  the  strike  group 
level.  The  Repetition  MOE  will  capture  how  easy  it  is  for  a  particular  training  simulation 
to  be  repeated  multiple  times  based  on  the  anticipated  time  commitment,  number  of 
players  involved,  access  to  the  required  hardware  or  software,  and  depending  on  how  the 
training  simulation  is  controlled. 

c.  MOE  5.3:  Retention 

This  MOE  measures  how  well  a  warfighter  or  unit  is  expected  to  retain  the 
information  and  experience  learned  during  training  simulations.  Retention  is  thought  to 
be  a  function  of  the  number  of  times  a  training  is  conducted  and  the  level  of  fidelity  for 
that  training.  While  this  is  a  qualitative  assessment,  it  is  thought  that  repetition  will  have 
a  larger  impact  than  fidelity  with  regard  to  retention. 
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F.  OVERALL  MEASURE  OF  EFFECTIVENESS 

The  Overall  Measure  of  Effectiveness  (OMOE)  is  a  means  of  assessing  the 
performance  of  alternative  systems  in  an  analysis  of  alternatives.  The  OMOE  process 
starts  with  engineers  determining  the  MOEs  by  a  system  can  be  evaluated,  then  they 
determine  the  Measures  of  Performance  (MOP)  for  each  MOE,  and  then  the  key 
performance  parameters  that  are  used  to  measure  those  MOPs  (Parnell,  Driscoll  and 
Henderson  2010). 

The  following  discussion  and  approach  to  swing  weights  follows  the  process  as 
laid  out  in  Parnell,  Driscoll,  and  Henderson’s,  Decision  Making  in  Systems  Engineering 
and  Management.  While  all  MOEs  and  MOPs  are  important,  some  are  more  important  to 
mission  accomplishment  than  others  and  should  be  weighted  more  significantly.  In  order 
to  account  for  this,  the  team  used  a  swing  weight  matrix  to  rank  the  importance  of  MOEs 
in  relation  to  each  other.  Once  the  ranking  relationship  of  the  MOEs  is  determined  a 
normalized  weighted  value  on  a  scale  of  zero  to  one  can  be  determined  to  account  for 
these  MOEs’  importance  (Parnell,  Driscoll  and  Henderson  2010). 

Since  the  WFTS  is  a  broad  architectural  concept  being  evaluated  as  a  qualitative 
assessment,  specific  performance  numbers  associated  with  evaluating  MOPs  would 
convey  little  value.  Therefore,  the  team  makes  a  qualitative  assessment  of  how  well  each 
alternative  is  expected  to  perform  the  MOEs.  The  qualitative  assessment  will  be 
normalized  as  a  value  ranging  from  zero  to  one. 

Once  the  normalized  swing  weights  and  normalized  values  for  the  MOEs  have 
been  determined,  the  OMOE  value  can  be  determined  using  Equation  1,  where  V(x)  is  the 
OMOE  for  design  alternative  jc,  wy  is  the  normalized  swing  weight  for  a  particular  MOE, 
and  v(xi)  is  the  MOE  qualitative  normalized  value  for  design  option  x  with  respect  to 
each  particular  MOE  (Parnell,  Driscoll  and  Henderson  2010,  295). 


ft 

F(x)  =  ^wiv(xi) 

i= 1 


(Eq.  1) 
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The  sum  product  of  these  two  values  results  in  an  OMOE  value  scaled  between 
zero  and  one  for  each  design  alternative.  These  OMOE  values  may  then  be  directly 
compared  across  the  design  alternatives  to  determine  which  design  was  assessed  to  have 
the  highest  performance. 

G.  DETERMINATION  OF  SWING  WEIGHTS 

In  order  to  determine  a  normalized  weight,  the  team  had  to  qualitatively  assess 
each  MOE  on  two  qualities.  The  first  was  how  large  a  capability  gap  is  the  MOE 
assessing,  and  the  second  is  how  important  is  the  MOE  to  the  mission.  The  capability  gap 
assessment  was  then  broken  into  three  sub-categories:  low,  medium,  and  high.  The  level 
of  importance  was  also  broken  into  three  categories:  mission  critical,  mission  effective, 
and  mission  enhancing.  This  breakdown  is  shown  in  Table  19. 


Table  19.  Swing  Weight  Identification  Matrix 


Level  of  Importance 

Mission 

Mission 

Mission 

Critical 

Effective 

Enhancing 

Capability 

Gap 

High 

A 

C 

F 

Medium 

B 

E 

H 

Low 

D 

G 

I 

Derived  from  Parnell,  Driscoll  and  Henderson  2010,  299. 


The  lettering  system  in  Table  19  indicates  the  cells  labeled  with  lower  alphabetic 
letters  are  more  important  than  the  other  cells  that  have  higher  alphabetic  letters.  In  other 
words,  A>B>C  and  so  forth.  If  multiple  MOEs  are  put  into  a  given  cell,  then  the  MOE  at 
the  top  of  the  cell  is  weighted  as  more  important  than  or  equal  to  the  ones  listed  below  it. 

Once  all  the  MOEs  have  been  assigned  a  proper  location  in  the  table,  and  using 
the  alphabetic  ranking  system,  we  can  assign  each  MOE  a  non-normaiized  value.  Once 
each  MOE  has  a  value,  those  values  can  then  be  normalized  to  a  value  between  zero  and 
one  using  Equation  2,  where  / ,  is  the  non-normalized  swing  weight  for  a  particular  MOE 
that  the  team  assigned  in  Table  20  (Parnell,  Driscoll,  and  Henderson  2010,  298). 
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(Eq.  2) 


Table  20  shows  each  MOE  that  the  team  identified  and  the  non-normalized  swing 
weight  ranking  of  each  MOE  in  reference  to  the  Table  19.  The  normalized  swing  weight 
values  for  all  the  MOEs  found  using  Equation  2  are  presented  in  Table  21. 


Table  20.  WFTS  Non-Normalized  Swing  Weight  Matrix 


Level  of  Importance 

Mission  Critical 

Mission  Effectiveness 

Mission  Enhancing 

MOE 

Score 

MOE 

Score 

MOE 

Score 

1.1 

99 

5.2 

79 

3.1 

45 

1.3 

98 

4.3 

78 

& 

o 

Large 

4.2 

73 

4.4 

70 

s 

Medium 

5.3 

88 

2.2 

58 

03 

& 

u 

5.1 

84 

4.1 

56 

Small 

1.2 

65 

2.3 

38 

2.1 

19 

4.5 

31 

Table  21.  WFTS  Normalized  Swing  Weight  Matrix 


Level  of  Importance 

Mission  Critical 

Mission  Effectiveness 

Mission  Enhancing 

MOE  Score 

MOE  Score 

MOE  Score 

Capability  Gap 

Large 

1.1  0.101 

1.3  0.100 

5.2  0.081 

4.3  0.080 

4.2  0.074 

4.4  0.071 

3.1  0.046 

Medium 

HH 

2.2  0.059 

4.1  0.057 

Small 

1.2  0.066 

2.3  0.039 

4.5  0.032 

2.1  0.019 
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H.  DETERMINATION  OF  QUALITATIVE  VALUES  FOR  MOES 


Each  MOE  for  each  alternative  is  based  upon  a  qualitative  scale  in  order  to 
determine  the  value  of  the  MOE  to  be  used  in  the  OMOE  process.  Table  22  shows  the 
qualitative  scale  that  the  team  used.  Table  23  shows  the  non-normalized  MOE  values, 
and  Table  24  shows  the  normalized  MOE  values. 


Table  22.  MOE  Assessment  Scale 


Assessment  Scale 

Value 

Normalized  Value 

Does  not  Meet  MOE 

0 

0 

Partially  Meets  MOE 

1 

0.25 

Fully  Meets  MOE 

2 

0.5 

Moderately  Exceeds  MOE 

3 

0.75 

Greatly  Exceeds  MOE 

4 

1 

Table  23.  Non-Normalized  MOE  Values 


Design  Alternative 


MOE 

Weight 

1 

2 

3 

4 

5 

6 

7 

8 

9 

1.1 

Fits  into  basic  phase 

0.101 

4 

2 

2 

2 

2 

0 

0 

4 

2 

1.2 

Fits  into  integrated  phase 

0.066 

4 

3 

3 

3 

2 

2 

3 

0 

0 

1.3 

Fits  into  sustainment  phase 

0.100 

4 

2 

2 

3 

2 

2 

0 

2 

2 

2.1 

Scenario  management 

0.019 

1 

2 

3 

3 

2 

3 

1 

4 

4 

2.2 

Understanding  enemy 

0.059 

4 

3 

3 

3 

3 

3 

2 

1 

1 

2.3 

Identify  warfighter  decisions 

0.039 

4 

3 

3 

3 

3 

3 

2 

1 

3 

3.1 

Automation  of  data  processing 

0.046 

4 

3 

2 

3 

2 

2 

0 

2 

2 

4.1 

Integration  within  units  or  simulators 

0.057 

4 

4 

4 

4 

2 

4 

3 

0 

0 

4.2 

Integration  between  units  and  simulators 

0.074 

4 

4 

0 

0 

3 

0 

1 

0 

0 

4.3 

Integration  at  sea 

0.080 

4 

4 

4 

4 

0 

4 

2 

0 

0 

4.4 

Integration  at  sea  with  in  port  unit 

0.071 

4 

0 

4 

0 

0 

0 

2 

0 

0 

4.5 

Integration  in  port 

0.032 

4 

0 

4 

0 

4 

0 

3 

0 

0 

5.1 

Fidelity 

0.086 

4 

3 

3 

3 

3 

3 

3 

1 

2 

5.2 

Repetition 

0.081 

3 

3 

2 

3 

3 

3 

1 

4 

4 

5.3 

Retention 

0.090 

3 

3 

2 

3 

3 

3 

2 

3 

3 
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Table  24.  Normalized  MOE  Values 


Design  Alternative 


MOE 

Weight 

1 

2 

3 

4 

5 

6 

7 

8 

9 

1.1 

Fits  into  basic  phase 

0.101 

1 

0.5 

0.5 

0.5 

0.5 

0 

0 

1 

0.5 

1.2 

Fits  into  integrated  phase 

0.066 

1 

0.75 

0.75 

0.75 

0.5 

0.5 

0.75 

0 

0 

1.3 

Fits  into  sustainment  phase 

0.100 

1 

0.5 

0.5 

0.75 

0.5 

0.5 

0 

0.5 

0.5 

2.1 

Scenario  management 

0.019 

0.25 

0.5 

0.75 

0.75 

0.5 

0.75 

0.25 

1 

1 

2.2 

Understanding  enemy 

0.059 

1 

0.75 

0.75 

0.75 

0.75 

0.75 

0.5 

0.25 

0.25 

2.3 

Identify  warfighter  decisions 

0.039 

1 

0.75 

0.75 

0.75 

0.75 

0.75 

0.5 

0.25 

0.75 

3.1 

Automation  of  data  processing 

0.046 

1 

0.75 

0.5 

0.75 

0.5 

0.5 

0 

0.5 

0.5 

4.1 

Integration  within  units  or 
simulators 

0.057 

1 

1 

1 

1 

0.5 

1 

0.75 

0 

0 

4.2 

Integration  between  units  and 
simulators 

0.074 

1 

1 

0 

0 

0.75 

0 

0.25 

0 

0 

4.3 

Integration  at  sea 

0.080 

1 

1 

1 

1 

0 

1 

0.5 

0 

0 

4.4 

Integration  at  sea  with  in  port 
unit 

0.071 

1 

0 

1 

0 

0 

0 

0.5 

0 

0 

4.5 

Integration  in  port 

0.032 

1 

0 

1 

0 

1 

0 

0.75 

0 

0 

5.1 

Fidelity 

0.086 

1 

0.75 

0.75 

0.75 

0.75 

0.75 

0.75 

0.25 

0.5 

5.2 

Repetition 

0.081 

0.75 

0.75 

0.5 

0.75 

0.75 

0.75 

0.25 

1 

1 

5.3 

Retention 

0.090 

1 

1 

1 

1 

1 

1 

1 

1 

1 

I.  OMOE  FOR  ALL  DESIGN  ALTERNATIVES 

Now  that  the  values  of  each  MOE  for  each  alternative  and  the  normalized  swing 
weights  have  been  determined,  the  OMOE  for  all  the  design  alternatives  can  be 
determined  using  Equation  1,  where  the  OMOE  is  the  sum  product  of  the  normalized 
weighted  values  and  the  normalized  qualitative  value  of  the  MOE.  Table  25  shows  the 
results  of  the  OMOE  analysis. 


Table  25.  OMOE  Values  for  Each  Design  Alternative 


Design 

Alternative 

1 

2 

3 

4 

5 

6 

7 

8 

9 

OMOE 

Value 

0.9429 

0.6705 

0.6498 

0.6259 

0.5474 

0.5224 

0.3932 

0.3869 

0.3772 
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The  design  alternatives  are  listed  again  here  for  convenience. 

1.  Fully  capable  system  addresses  all  major  capability  gaps  identified. 

2.  Strike  group  out  to  sea  integrated  with  a  shore  based  simulator  network. 

3.  A  ship  out  to  sea  integrated  with  a  ship  in  port. 

4.  A  squadron  of  similar  units  integrating  for  training  out  to  sea. 

5.  Ships  in  port  integrating  with  a  shore  based  simulator. 

6.  A  strike  group  conducting  sustainment  training  at  sea. 

7.  Fleet  synthetic  training  exercise  integrating  in  port  or  at  sea  units  during 
the  integrated  phase. 

8.  Low  fidelity  trainer  integrating  units  at  sea  and  in  port. 

9.  Single  unit  in  port  being  fed  a  scenario  from  a  local  training  center. 

Table  25  indicates  that  DAI  had  the  highest  training  value  as  determined  by  its 
OMOE,  while  DA9  had  the  lowest  training  value.  It  should  be  expected  that  DAI  has  the 
highest  value  as  this  system  was  designed  to  allow  for  webfires  training  under  all 
anticipated  conditions  and  during  all  phases  of  the  OFRP. 

The  purpose  in  determining  the  OMOE  for  each  design  alternative  is  to  determine 
which  alternative  had  the  best  score  and  to  allow  for  comparisons  between  alternatives. 
The  real  value  of  Table  25  is  that  it  shows  the  relative  scores  of  the  different  design 
alternatives  and  how  they  compare.  Design  alternatives  two,  three,  and  four  were  all  very 
comparable  in  training  value,  while  alternatives  five  and  six  were  grouped  close  together, 
and  finally  seven,  eight,  and  nine  were  grouped  close  together. 

Additionally,  if  a  decision  maker  were  to  determine  they  do  not  need  all  of  the 
capabilities  provided  in  DAI,  or  the  budget  does  not  support  DAI,  that  decision  maker 
could  look  at  the  other  alternatives  and  choose  a  lower  cost  option  with  less  capability. 
The  OMOE  values  provide  an  indication  of  the  abstract  potential  value  of  the  WFTS  that 
is  gained  or  lost  depending  on  the  design  alternative  chosen. 

As  a  budget  is  not  available  for  consideration,  and  the  costs  of  these  design 

alternatives  are  not  being  considered,  the  natural  recommendation  is  to  move  forward 
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with  DAI.  It  is  important  to  note  that  the  OMOEs  calculated  in  Table  25  are  the  result  of 
the  weights  and  scores  determined  by  the  team  after  consultation  with  stakeholders. 
Individual  stakeholders  may  regard  each  MOE  with  a  different  weight,  or  assess  an 
alternative’s  performance  in  that  MOE  differently.  To  explore  the  possible  impact  of 
changing  the  weights  on  the  OMOE  values,  a  sensitivity  analysis  was  conducted.  This 
process  will  be  discussed  in  the  following  section. 

J.  SENSITIVITY  ANALYSIS  PROCESS 

The  identification  of  the  swing  weights  above  is  subjective,  therefore,  the  ranking 
of  alternatives  may  be  sensitive  to  variations  in  the  weighted  value  resulting  in  one 
alternative’s  OMOE  being  higher  than  another.  It  is  important  to  perform  sensitivity 
analysis  to  show  the  stakeholder  that  while  a  particular  alternative  may  have  a  higher 
OMOE  based  on  the  current  assessment  scale,  minor  changes  in  preference  could  result 
in  different  alternatives  having  higher  OMOE  values.  This  can  then  be  used  to  aid  in 
determining  the  most  appropriate  design  alternative  and  help  inform  decision  makers 
about  potential  risk  and  uncertainty. 

In  order  to  determine  the  sensitivity  of  a  particular  swing  weight  the  following 
information  needs  to  be  determined,  as  shown  in  Table  26. 


Table  26.  Information  for  Sensitivity  Analysis 


Information 

Description 

Y, 

Current  OMOE  value  for  Alternative 

y2 

Normalized  MOE  value  for  associated  Swing  Weight  being  assessed 

X, 

Normalized  Swing  Weight  value  for  MOE  being  assessed 

X2 

Value  is  1 

Table  27  shows  the  calculations  performed  for  DAI.  This  information  will  be 
used  to  aid  the  reader  in  understanding  how  sensitivity  analysis  was  performed.  The  same 
calculations  were  repeated  for  each  design  alternative. 
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Table  27.  Sensitivity  Analysis  Calculations  for  DAI 


MOEs 

Normalized 

Swing 

Weight 

(Wi) 

Option 

MOE 

value 

(Vi) 

Product 
(Wi  x  Vi) 

1.1 

Fits  into  Basic  Phase 

1 

0.1009 

1.2 

Fits  into  Integrated 

1 

0.0663 

1.3 

Fits  into  Sustainment 

1 

0.0999 

2.1 

Scenario  Management 

0.019 

0.25 

0.0048 

2.2 

Understanding  Enemy 

0.059 

1 

0.0591 

2.3 

Identify  warfighter  decisions 

0.039 

1 

0.0387 

3.1 

Automation  of  Data  Processing 

0.046 

1 

0.0459 

4.1 

Integration  within  units  or  simulators 

0.057 

1 

0.0571 

4.2 

Integration  between  units  and  simulators 

0.074 

1 

0.0744 

4.3 

Integration  at  sea 

0.080 

1 

0.0795 

4.4 

Integration  at  sea  with  in  port  unit 

0.071 

1 

0.0714 

4.5 

Integration  in  Port 

0.032 

1 

0.0316 

5.1 

Fidelity 

0.086 

1 

0.0856 

5.2 

Repetition 

0.081 

0.75 

0.0604 

5.3 

Retention 

0.090 

0.75 

0.0673 

OMOE 

Option 

0.9429 

Using  the  sample  data  from  Table  27,  Table  28  will  show  the  sensitivity  data 
needed  for  sensitivity  analysis. 


Table  28.  Sample  Data  for  Sensitivity  Analysis  of  MOE  1.1 


Information 

Sample  Data 

Yi 

.9429 

y2 

1 

Xi 

0.101 

X2 

1 

Using  the  equation  for  the  determination  of  the  slope  of  a  linear  line  and  the 
equation  for  a  linear  line;  the  slope  and  y-intercept  can  be  determined  and  plotted  on  a 
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graph.  This  process  is  repeated  for  each  design  alternative  and  can  then  be  plotted  as 
shown  in  Figure  38. 

Once  the  equations  for  all  the  other  design  alternatives  have  been  determined  and 
plotted,  the  team  can  then  see  if  these  lines  cross.  The  value  for  a  particular  swing  weight 
that  would  result  in  an  alternative  being  chosen  over  another  alternative  can  be  observed 
at  the  intersections  of  lines.  That  swing  weight  value  can  be  calculated  by  taking  the 
equation  of  two  lines  that  cross,  setting  them  equal  to  each  other,  and  then  solving  for  the 
swing  weight  value  using  algebra. 

The  next  section  of  this  report  will  show  the  results  of  the  team’s  sensitivity 
analysis.  Although  all  MOES  were  analyzed,  only  the  relevant  MOEs  that  are  sensitive 
will  be  discussed  below. 

K.  SENSITIVITY  ANALYSIS  RESULTS 

Sensitivity  analysis  was  conducted  for  the  top  four  design  alternatives,  DAI 
through  DA4,  using  spreadsheet  software.  There  were  a  total  of  eight  instances  where 
changing  the  swing  weights  would  change  the  order  of  the  OMOEs,  and  only  one  of 
those  instances  where  DAI  was  no  longer  the  highest  OMOE.  Each  of  those  instances 
will  be  discussed  in  more  detail  according  to  the  affected  MOE  weights. 

1.  MOE  1.3  Fits  into  Sustainment  Phase 

For  all  MOE  1.3  weights,  DAI  remains  the  preferred  design,  but  the  order  of 
some  of  the  other  designs  change  as  the  MOE  weight  changes.  The  current  weight  for 
MOE  1.3  is  0.102.  DA3  is  dominated  by  DA4  once  the  weight  increases  to  0.18,  while 
DA2  is  then  dominated  by  DA4  for  MOE  1.3  weights  greater  than  0.24.  Figure  38  shows 
the  impact  of  MOE  1.3  weight  on  the  first  four  design  alternatives. 
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Figure  38.  MOE  1.3  Sensitivity  Analysis 

2.  MOE  2.1  Scenario  Management 

This  is  the  only  weight  where  DAI  does  not  always  dominate  the  other  designs. 
The  current  weight  for  MOE  2.1  is  0.020.  If  this  weight  is  increased  beyond  0.38  DAI 
becomes  dominated  by  DA3,  with  DA3  remaining  the  preferred  design.  Figure  39  shows 
the  impact  of  MOE  2. 1  weight  on  the  first  four  design  alternatives. 


Figure  39.  MOE  2.1  Sensitivity  Analysis 
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3. 


MOE  3.1  Automation  of  Data  Processing 


For  all  MOE  3.1  weights,  DAI  remains  the  preferred  design,  but  the  order  of 
some  of  the  other  designs  change  as  the  MOE  weight  changes.  The  current  weight  for 
MOE  3.1  is  0.036.  DA3  is  dominated  by  DA4  once  the  weight  increases  to  0.13.  Figure 
40  shows  the  impact  of  MOE  3.1  weight  on  the  first  four  design  alternatives. 


Figure  40.  MOE  3.1  Sensitivity  Analysis 


4.  MOE  4.2  Integration  between  Units  and  Simulators 

For  all  MOE  4.2  weights,  DAI  remains  the  preferred  design,  but  the  order  of 
some  of  the  other  designs  change  as  the  MOE  weight  changes.  The  current  weight  for 
MOE  4.2  is  0.066.  DA4  is  dominated  by  DA2  once  the  weight  increases  to  0.03,  while 
DA3  is  then  dominated  by  DA2  for  MOE  4.2  weights  greater  than  0.05.  Figure  41  shows 
the  impact  of  MOE  4.2  weight  on  the  first  four  design  alternatives. 
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-DAI 


-DA2 


Figure  41.  MOE  4.2  Sensitivity  Analysis 


5.  MOE  4.4  Integration  at  sea  with  in  Port  Unit 

For  all  MOE  4.4  weights,  DAI  remains  the  preferred  design,  but  the  order  of 
some  of  the  other  designs  change  as  the  MOE  weight  changes.  The  current  weight  for 
MOE  4.4  is  0.066.  DA4  is  dominated  by  DA3  once  the  weight  increases  to  0.05,  while 
DA2  is  then  dominated  by  DA3  for  MOE  4.4  weights  greater  than  0.09.  Figure  42  shows 
the  impact  of  MOE  4.4  weight  on  the  first  four  design  alternatives. 


Figure  42.  MOE  4.4  Sensitivity  Analysis 
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6. 


MOE  4.5  Integration  in  Port 


For  all  MOE  4.5  weights,  DAI  remains  the  preferred  design,  but  the  order  of 
some  of  the  other  designs  change  as  the  MOE  weight  changes.  The  current  weight  for 
MOE  4.5  is  0.043.  DA4  is  dominated  by  DA3  once  the  weight  increases  to  0.008,  while 
DA2  is  then  dominated  by  DA3  for  MOE  4.5  weights  greater  than  0.05.  Figure  43  shows 
the  impact  of  MOE  4.5  weight  on  the  first  four  design  alternatives. 


Figure  43.  MOE  4.5  Sensitivity  Analysis 


7.  MOE  5.2  Repetition 

For  all  MOE  5.2  weights,  DAI  remains  the  preferred  design,  but  the  order  of 
some  of  the  other  designs  change  as  the  MOE  weight  changes.  The  current  weight  for 
MOE  5.2  is  0.072.  DA3  is  dominated  by  DA4  for  all  weights  greater  than  0.16.  Figure  44 
shows  the  impact  of  MOE  5.2  weight  on  the  first  four  design  alternatives. 
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Figure  44.  MOE  5.2  Sensitivity  Analysis 


8.  MOE  5.3  Retention 

For  all  MOE  5.3  weights,  DAI  remains  the  preferred  design,  but  the  order  of 
some  of  the  other  designs  change  as  the  MOE  weight  changes.  The  current  weight  for 
MOE  5.3  is  0.092.  DA3  is  dominated  by  DA4  for  all  weights  greater  than  0.17.  Figure  45 
shows  the  impact  of  MOE  5.3  weight  on  the  first  four  design  alternatives. 


Figure  45.  MOE  5.3  Sensitivity  Analysis 
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X.  SYSTEM  ARCHITECTURE 


System  architecture  is  a  means  of  conveying  the  complexity  of  a  system  in  ways 
that  can  show  its  properties,  relationships,  and  behaviors  from  different  viewpoints  (DOD 
Deputy  Chief  Information  Officer  2017a).  The  process  is  similar  to  traditional 
architecture,  where  an  architect  will  create  multiple  blue  prints  or  drawings  to  describe  a 
structure.  To  further  the  example,  one  blueprint  may  be  an  illustration  that  shows  the 
architecturally  significant  aspects  of  a  structure  to  a  customer  financing  a  house,  while 
another  blueprint  for  the  general  contractor  may  be  more  detailed,  showing  the  home’s 
electrical  wiring  plan.  In  both  architecture  and  systems  engineering,  there  is  a  need  for 
multiple  views  that  must  be  modeled  from  different  perspectives  in  order  to  design  and 
build  a  complex  system. 

For  the  purpose  of  this  report,  the  DOD  Architectural  Framework  (DoDAF)  will 
be  used  to  depict  these  viewpoints.  The  DoDAF  is  the  standard  used  by  the  DOD  and  will 
allow  for  common  understanding.  Some  non-DoDAF  tools  have  been  incorporated  in  the 
following  discussion  to  show  views  of  the  system  that  are  important  but  have  no 
corresponding  standard  DoDAF  view. 

A.  ARCHITECTURAL  OVERVIEW 

The  team  completed  the  process  of  problem  identification,  stakeholder 
identification,  gap  analysis,  and  CONOPS  generation  that  enabled  the  determination  of 
capabilities  requirements.  The  WFTS  needs  to  fill  the  capability  gaps  that  were 
determined  through  research  and  stakeholder  engagement.  The  capabilities  requirements 
allowed  for  the  determination  of  operational  activities  (organizational  functions)  that 
must  be  performed  by  the  nodes  (organizations).  After  nodes  (organizations)  and 
operational  activities  where  determined,  the  operational  items  (information  passing 
between  organizational  functions)  were  determined.  This  then  allowed  for  needlines 
(communication  pathways  between  nodes)  to  be  determined  to  support  the  exchange  of 
operational  items.  After  all  of  these  were  determined,  the  team  could  then  identify  the 
functions  and  functional  requirements  that  components  (hardware/software)  would  have 
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to  meet  in  order  to  support  the  operational  activities  and  meet  the  capabilities 
requirements  of  the  system.  Finally,  using  an  analysis  of  alternatives  approach,  the  team 
determined  a  final  design  of  components  that  would  best  fulfill  the  capability 
requirements  of  the  system. 

The  organizations,  components,  requirements,  and  functions  (people  and  system) 
and  their  inter-relationships  that  are  necessary  to  fill  the  capability  gaps  are  shown  in 
Figure  46.  They  are  discussed  in  greater  detail  throughout  this  chapter. 


Adapted  from  CORE  Architecture  Definition  Guide  (DoDAF  v2.02). 
Figure  46.  WFTS  Architectural  Overview 


B.  ARCHITECTURAL  VIEWPOINTS 

The  success  of  any  system  depends  on  the  foundation  provided  to  design, 
implement,  support,  and  potentially  build  upon,  improve,  or  expand  that  system.  This 
creates  a  synergistic  relationship  that  converts  raw  material  and  data  entering  a  well- 
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designed  system  into  a  viable  end-product  that  meets  or  exceeds  customer  needs  and 
requirements.  The  viewpoints  that  are  used  to  show  the  relationships  are  described  briefly 
in  Table  26. 


Table  29.  Architectural  Viewpoints 


View  Point 

Description 

Operational  Resource  Flow 
Description  (OV-2) 

Shows  the  nodes  (organizations)  and  the 
needlines  (communication  connections) 
between  other  nodes. 

Operational  Items  Transfer 
Matrix 

Shows  the  operational  items 
(information)  that  is  being  passed  along 
each  needline  that  connects  each  node. 

State  Transition  Description 
(OV-6b) 

Shows  the  sequencing  of  the  operational 
activities. 

Operational  Activity  Model 
(OV-5b) 

Shows  the  nodes,  operational  activities 
that  they  perform,  and  the  operational 
items  that  are  being  passed  between 
operational  activities. 

Capability  to  Operation 

Activity  Mapping  (CV-6) 

Shows  the  capabilities  that  each 
operational  activity  is  supporting. 

Operational  Activity  to 

Systems  Function  Traceability 
Matrix  (SV-5a) 

Shows  the  functions  of  the  system  that 
implement/support  the  operational 
activities. 

Functions  to  Systems 
Traceability  Matrix 

Shows  what  components  comprise  the 
system,  what  functions  each  component 
performs,  and  what  operational  activity  it 
supports  when  combined  with  the  SV-5a. 

Capability  Requirements  to 
Functional  Requirements 
Traceability  Matrix 

Shows  the  mapping  between  functional 
requirements  and  capability  requirements. 

Functional  Requirements  to 
Functions  Traceability  Matrix 

Shows  the  mapping  between  functions 
and  functional  requirements. 

1.  Operational  Resource  Flow  Description  for  Webfires  Training  (OV-2) 

This  section  shows  the  nodes  (or  organizations)  that  make  up  the  WFTS  and  the 
needlines  that  connect  these  organizations.  The  relationship  that  this  architectural  view  is 
focusing  on  in  relation  to  the  architectural  overview  in  Section  A  is  shown  in  Figure  47. 
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Adapted  from  CORE  Architecture  Definition  Guide  (DoDAF  v2.02). 
Figure  47.  OV-2  Relationship  to  Overall  System  Architecture 


According  to  DoDAF  Version  2.02: 

The  OV-2  can  be  used  to  show  flows  of  funding,  personnel  and  materiel  in 
addition  to  information.  A  specific  application  of  the  OV-2  is  to  describe  a 
logical  pattern  of  resource  (information,  funding,  personnel,  or  materiel) 
flows.  The  logical  pattern  need  not  correspond  to  specific  organizations, 
systems  or  locations,  allowing  Resource  Flows  to  be  established  without 
prescribing  the  way  that  the  Resource  Flows  are  handled  and  without 
prescribing  solutions. 

The  intended  usage  of  the  OV-2  includes: 

•  Definition  of  operational  concepts. 

•  Elaboration  of  capability  requirements. 

•  Definition  of  collaboration  needs. 

•  Applying  a  local  context  to  a  capability. 

•  Problem  space  definition. 

•  Operational  planning. 

•  Supply  chain  analysis. 

•  Allocation  of  activities  to  resources.  (DOD  Deputy  Chief  Information 
Officer  2017c) 

Figure  48  shows  the  organizations  that  are  involved  in  the  WFTS,  which 

organizations  pass  information  between  each  other,  and  the  general  information  passed 
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Enemy  Treat 


between  them.  Each  needline  represents  information  flow  and  can  be  either  an  input, 
output,  or  both  (represented  by  the  directional  arrows)  from  individual  organizations. 


Figure  48.  WFTS  OV-2 


2.  Operational  Items  Transfer  Matrix 

The  Operational  Items  Transfer  Matrix,  as  shown  in  Appendix  D,  Section  A, 
describes  in  more  detail  what  nodes  are  connecting  to  each  other  and  exactly  what  each 
node  is  exchanging  with  the  other.  This  matrix,  along  with  the  OV-2,  can  aid  the  reader 
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in  understanding  what  and  how  the  organizations  can  communicate  in  order  to  meet  the 
capability  requirements. 

3.  State  Transition  Description  (OV-6b) 

According  to  DoDAF  Version  2.02: 

The  OV-6b  is  a  graphical  method  of  describing  how  an  operational 

activity  responds  to  various  events  by  changing  its  state. 

The  intended  usage  of  the  OV-6b  includes: 

•  Analysis  of  business  events. 

•  Behavioral  analysis. 

•  Identification  of  constraints.  (DOD  Deputy  Chief  Information  Officer 

2017e) 

Figure  49  shows  the  three  different  states  or  phases  (Support  Training,  Conduct 
Training,  and  Evaluate  Training)  that  the  WFTS  operates  under  in  order  to  provide 
training.  Each  one  of  these  phases  has  different  operational  activities  assosciated  with  it 
and  has  different  organizations  that  are  involved  in  each.  The  figure  also  shows  that  this 
is  an  iterative  loop  that  is  completed  multiple  times  to  support  all  phases  of  the  OFRP. 
This  section  discusses  each  one  of  the  phases  in  more  detail. 


Figure  49.  WFTS  State  Diagram  (OV6b) 


4.  Operational  Activity  Model  (OV-5b) 

Figure  50  shows  the  relationship  that  the  OV-5b  has  to  the  architectural  overview 
in  Section  A.  An  OV-5b  is  shown  for  each  one  of  the  operational  activities  shown  in 
Figure  49.  Each  OV-5b  shows  the  nodes  (Organizations)  that  are  involved  in  that  phase, 
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what  operational  activities  they  perform,  and  the  Operational  Items  that  are  shared 
between  the  operational  activities. 


Nodes 


Performs 


Operational 

Items 


/Inputs/Outputs/Triggers 


Operational 

Activities 


Adapted  from  CORE  Architecture  Definition  Guide  (DoDAF  v2.02) 

Figure  50.  OV-5b  Relationship  to  Architectural  Overview 


According  to  DoDAF  Version  2.02: 

The  OV-5a  and  the  OV-5b  describe  the  operations  that  are  normally 
conducted  in  the  course  of  achieving  a  mission  or  a  business  goal.  It 
describes  operational  activities  (or  tasks);  Input/  Output  flows  between 
activities,  and  to/from  activities  that  are  outside  the  scope  of  the 
Architectural  Description. 

The  OV-5a  and  OV-5b  describes  the  operational  activities  that  are  being 
conducted  within  the  mission  or  scenario.  The  OV-5a  and  OV-5b  can  be 
used  to: 

•  Clearly  delineate  lines  of  responsibility  for  activities  when  coupled  with 
OV-2. 

•  Uncover  unnecessary  operational  activity  redundancy. 

•  Make  decisions  about  streamlining,  combining,  or  omitting  activities. 
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•  Define  or  flag  issues,  opportunities,  or  operational  activities  and  their 
interactions  (information  flows  among  the  activities)  that  need  to  be 
scrutinized  further. 

The  intended  usage  of  the  OV-5a  and  OV-5b  includes: 

•  Description  of  activities  and  workflows. 

•  Requirements  capture. 

•  Definition  of  roles  and  responsibilities. 

•  Support  task  analysis  to  determine  training  needs. 

•  Problem  space  definition. 

•  Operational  planning. 

•  Logistic  support  analysis. 

•  Information  flow  analysis.  (DOD  Deputy  Chief  Information  Officer 
2017d) 

How  to  Read  Figure  51,  Figure  52,  and  Figure  53: 

Each  parallel  line  represents  a  node.  Along  those  lines  are  boxes  that  represent  the 
operational  activities  that  those  nodes  perform.  Passing  between  those  operational 
activities  are  operational  items.  The  arrows  indicate  the  flow  of  operational  items  from 
one  operational  activity  to  the  next  and  show  the  operational  activities  that  must  be 
accomplished  prior  to  the  next  operational  activity. 

Figure  51  shows  the  operational  activities  that  the  Intelligence  Community, 
Numbered  Fleet,  TACTRAGRU,  TYCOM,  NWDC,  and  CSG/ESG  CMDR  perform 
during  the  Support  Training  phase  of  the  WFTS.  During  this  phase,  NWDC  develops 
TTPs  that  are  then  passed  to  the  numbered  fleet  and  TYCOM.  Additionally,  the 
intelligence  community  will  pass  intelligence  to  the  other  organizations.  TACTRAGRU, 
TYCOM,  Numbered  Fleet,  and  the  CSG/ESG  CMDR  can  then  create  different  training 
scenarios  (simulations)  for  Units,  Simulators,  or  Strike  Groups  that  fit  into  the  Basic, 
Integrated,  and  Sustainment  Phases  of  the  OFRP. 
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Figure  51.  Support  Training  0V-5b 

After  the  scenarios  have  been  created,  the  WFTS  transitions  to  the  next  phase. 
Figure  52.  shows  the  Conduct  Training  operational  activity.  During  this  phase  of  the 
WFTS,  units  and  simulators  receive  scenarios  and  intelligence  that  were  generated  and 
collected  in  the  previous  phase.  This  enables  units  to  conduct  a  variety  of  different 
training  (in-port,  at-sea,  unit,  multi-unit,  or  any  combination).  As  units  and  simulators 
conduct  this  training  they  are  supported  by  the  Numbered  Fleet,  TACTRAGRU, 
TYCOM,  and  the  CSG/ESG  CMDR,  who  can  provide  simulation  control  in  order  to  help 
units  meet  certain  training  objectivesrequired  to  advance  through  the  Basic,  Integrated, 
and  Sustainment  Phases  of  the  OFRP.  After  a  unit  or  simulator  conducts  training  it  will 
then  provide  feedback  data  that  is  used  in  the  next  operational  activity. 
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Figure  52.  Conduct  Training  OV-5b 


Figure  53  shows  the  feedback  data  supplied  to  the  Numbered  Fleet,  CSG-4/15, 
TYCOM,  or  CSG/ESG  CMDR  for  evaluation  or  certification  purposes.  Additionally,  that 
data  is  passed  to  the  NWDC  so  that  it  can  be  used  to  assess  the  TTPs  that  the  Fleet  is 
employing  and  how  effective  they  are  against  a  near-peer  threat.  If  deemed  necessary,  the 
NWDC  can  then  update  the  TTPs  to  allow  the  fleet  to  better  react  to  an  enemy  threat. 
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Figure  53.  Evaluate  Training  0V-5b 


5.  Capability  to  Operation  Activity  Mapping  (CV-6) 

Figure  54  shows  the  relationship  that  the  CV-6  has  to  the  architectural  overview 
shown  in  Section  A  of  this  chapter.  A  CV-6  maps  the  capability  requirements  that  the 
system  must  have  to  the  operational  activities  that  are  used  to  support  those  capability 
requirements.  The  Webfires  training  system  CV-6  is  located  in  Appendix  D,  Section  B. 
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Adapted  from  CORE  Architecture  Definition  Guide  (DoDAF  v2.02). 
Figure  54.  CV-6  Relationship  to  Overall  Architecture 


According  to  DoDAF  Version  2.02: 

The  CV-6  describes  the  mapping  between  the  capabilities  required  and  the 
activities  that  enable  those  capabilities. 

The  intended  usage  of  the  CV-6  includes: 

•  Tracing  capability  requirements  to  operational  activities. 

•  Capability  audit.  (DOD  Deputy  Chief  Information  Officer  2017b) 

6.  Operational  Activity  to  System  Function  Traceability  Matrix  (SV-5a) 

Figure  55  shows  the  relationship  that  the  SV-5a  has  to  the  architectural  overview 
shown  in  Section  A  of  this  chapter.  An  SV-5a  maps  the  Functions  to  the  operational 
activities  that  they  support.  This  view  can  be  seen  in  Appendix  D,  Section  C. 


Operational 

implemented  By 

Activities 

Adapted  from  CORE  Architecture  Definition  Guide  (DoDAF  v2.02). 
Figure  55.  SV-5a  Relationship  to  Architectural  Overview 
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According  to  DoDAF  Version  2.02: 

The  SV-5a  addresses  the  linkage  between  System  Functions  [...]  and  operational 
activities  specified  in  OV-5a  operational  activity  Decomposition  Tree  or  OV-5b 
operational  activity  Model. 

The  intended  usage  of  the  SV-5a  includes: 

•  Tracing  functional  system  requirements  to  user  requirements. 

•  Tracing  solution  options  to  requirements. 

•  Identification  of  overlaps  or  gaps.  (DOD  Deputy  Chief  Information 
Officer  2017f) 

7.  Function  to  System  Traceability  Matrix 

Figure  56  shows  the  relationship  that  the  Functions  to  Systems  Traceability 
Matrix  has  to  the  architectural  overview  found  in  Section  A  of  this  chapter.  A  functions 
to  systems  traceability  matrix  maps  functions  to  components  that  comprise  the  overall 
system  architecture.  This  viewpoint  is  shown  in  Table  30. 


Adapted  from  CORE  Architecture  Definition  Guide  (DoDAF  v2.02). 

Figure  56.  Functions  to  Systems  Traceability  Matrix  Relationship  to  Overall 

Architecture 
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Table  30.  WFTS  Functions  to  Systems  Traceability  Matrix 


Component 

Function  Performs 

Artificial  Intelligence  Control  of  Simulation  System 

F.  1  Provide  Simulation 

Centralized  Data  Storage  System 

F.5  Store  Feedback  Data 

Combat  Systems 

F.3.1  Stimulate  Sensors  on  Units 

Hardwire  Communication  System 

F.2  Communicate 

LOS  Communication  System 

F.2  Communicate 

Manual  Control  of  Simulation  System 

F.  1  Provide  Simulation 

Mesh  Network  Topology 

F.4  Interface  With  Network 

OTH  Communications  System 

F.2  Communicate 

Sat  LOS  Communication  System 

F.2  Communicate 

Simulated  Combat  Systems 

F.3.2  Stimulate  Simulators 

Unit  Control  System 

F.3.3  Control  Simulations 

8.  Capability  Requirements  to  Functional  Requirements  Traceability 
Matrix 

Figure  57  shows  the  relationship  that  the  Capability  Requirements  to  Functional 
Requirements  Traceability  Matrix  has  to  the  architectural  overview  found  in  Section  A  of 
this  chapter.  This  figure  shows  that  the  functional  requirements  map  back  to  capability 
requirements.  The  traceability  matrix  is  shown  in  Appendix  D,  Section  D. 
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Implemented  By 

Functional 

Requirements 

Requirements 

Adapted  from  CORE  Architecture  Definition  Guide  (DoDAF  v2.02). 

Figure  57.  Capability  Requirement  to  Functional  Requirement  Traceability 
Matrix  Relationship  to  Overall  Architecture 

9.  Functional  Requirements  to  Functions  Traceability  Matrix 

Figure  58  shows  the  relationship  that  the  functional  requirements  to  functions 
traceability  matrix  has  to  the  architectural  overview  found  in  Section  A  of  this  chapter. 
System  Functions  are  needed  to  meet  Functional  Requirements.  The  traceability  matrix 
can  be  found  in  Appendix  D,  Section  E. 
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Adapted  from  CORE  Architecture  Definition  Guide  (DoDAF  v2.02). 

Figure  58.  Functional  Requirements  to  Functions  Traceability  Matrix 
Relationship  to  Overall  Architecture 
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XI.  SUMMARY,  CONCLUSIONS,  AND  RECOMMENDATIONS 


A.  SUMMARY 

The  nature  of  naval  warfare  is  continuously  evolving.  The  traditional  kill  chain 
approach  is  expected  to  be  insufficient  to  neutralize  near-peer  threats  in  the  future.  To 
increase  the  combat  effectiveness  of  the  U.S.  Navy  in  a  future  combat  environment,  the 
Navy  is  shifting  its  warfighting  approach  to  a  kill  web,  or  webfires,  concept  of 
operations.  In  his  2016  interview  with  the  U.S.  Naval  Institute,  Admiral  Manazir  postures 
that  unlike  the  current  kill  chain  process  where  units  are  limited  to  engagements  utilizing 
organic  sensor  data,  future  units  will  instead  be  able  to  work  together  to  "create  a  cross¬ 
domain  kill  web"  able  to  share  combat-relevant  data  for  the  purpose  of  tracking  and 
engaging  an  adversary  (Manazir  2016).  This  shift  in  the  way  the  Navy  fights  calls  for  a 
new  approach  to  training  the  Navy’s  future  warfighter.  This  report  details  a  systems 
engineering  approach  for  developing  a  webfires  training  system  (WFTS)  to  prepare  the 
future  warfighter  for  an  engagement  with  a  near-peer  threat. 

Using  the  systems  engineering  process,  the  project  team  used  a  methodical 
approach  to  problem  identification  to  derive  a  problem  from  the  tasking  statement  issued 
by  the  primary  stakeholder  (OPNAV  N9I  -  Director  of  Warfare  Integration).  This 
approach  included  extensive  research,  stakeholder  identification,  and  stakeholder 
engagement,  which  helped  refine  and  scope  this  capstone.  Once  the  research  on  the 
current  Navy  training  and  OFRP  cycle  was  completed,  along  with  stakeholder  research,  a 
gap  analysis  was  performed  to  determine  what  the  current  training  system  lacked  in 
providing  webfires  training.  This  study  identified  four  key  capability  gaps:  the  absence  of 
any  webfires  concept  training  today,  a  lack  of  multi-unit  training  repetition  to  support 
high-velocity  learning,  a  lack  of  compatible  networks  to  support  webfires  training,  and  a 
lack  a  quality  feedback  to  facilitate  high-velocity  learning. 

The  Navy  is  currently  developing  the  webfires  concept.  The  recent  deployment  of 
the  first  capable  Naval  Integrated  Fire  Control  -  Counter  Air  (NIFC-CA)  strike  group 
demonstrates  that  such  a  concept  is  being  developed  and  implemented  by  the  fleet.  The 
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implementation  of  NIFC-CA  is  just  one  small  aspect  of  the  webfires  concept.  If  all 
Carrier  Strike  Group  or  Expeditionary  Strike  Group  (CSG/ESG)  units  are  able  to  share 
fire  control  data  with  each  other,  then  the  webfires  concept  can  be  implemented  across 
the  air,  surface,  and  undersea  warfare  domains  (Manazir  2016).  For  warfighters  to 
implement  this  advanced  weapons  system  effectively,  they  require  doctrine.  This  report 
recommends  that  the  Naval  Warfare  Development  Center  (NWDC)  coordinate  with  the 
other  warfare  development  centers  to  document  a  unified  set  of  tactics,  techniques,  and 
procedures  (TTPs)  that  can  be  used  by  all  warfighters  to  implement  and  train  for 
webfires. 

Additionally,  the  network  capability  of  today’s  training  system  is  not  robust 
enough  to  support  the  repetition  necessary  to  facilitate  high-velocity  learning  and  in  turn 
results  in  less  efficient  multi-unit  training.  Currently,  the  only  complete  CSG/ESG  multi¬ 
unit  training  is  performed  during  Composite  Training  Unit  Exercises  (COMPTUEX) 
within  the  integrated  phase  of  the  Optimized  Fleet  Response  Plan  (OFRP)  to  certify  a 
CSG  or  ESG  for  deployment  and  entry  into  the  sustainment  phase  of  the  OFRP. 
Currently,  the  Tactical  Training  Groups  (TTG)  have  the  ability  to  facilitate  fleet  synthetic 
training  (FST)  events  prior  to  COMPTUEX.  However,  due  to  the  nature  of  the  training 
network  and  the  reliance  on  large  numbers  of  people  to  conduct  these  FST  events,  the 
TTGs  can  only  perform  one  simulation  at  a  time.  A  more  robust,  decentralized  training 
network  along  with  a  database  of  preprogrammed  training  simulations  would  greatly 
enhance  the  potential  for  more  frequent  integrated  training. 

Lastly,  repetition  is  only  one  aspect  of  high-velocity  learning.  For  high-velocity 
learning  to  be  successful,  training  must  be  current,  accurate,  and  relevant.  This  report 
recommends  that  the  future  WFTS  collect  and  produce  data  that  can  be  used  by  the 
NWDC  to  assess  the  current  doctrine  used  to  engage  a  near-peer  threat.  By  incorporating 
a  feedback  loop  into  the  training  system,  the  doctrine  can  be  updated  to  reflect  better 
approaches  to  attacking  an  enemy  during  the  training  process,  and  correct  deficiencies 
discovered  in  the  doctrine.  Additionally,  the  collected  data  could  be  used  by  the 
appropriate  teams  in  certifying  and  evaluating  units  for  deployment.  This  could 
potentially  reduce  training  and  certification  requirements.  However,  for  this  feedback 
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loop  to  work,  the  NWDC,  along  with  the  certification  and  evaluation  teams,  must 
establish  well-defined  data  collection  and  data  processing  requirements. 

B.  CONCLUSIONS  AND  RECOMMENDATIONS 

The  following  conclusions  and  recommendations  will  support  the  U.S.  Navy  in 
implementing  the  WFTS: 

1.  Training  System  Architecture  for  Webfires  Concept 

The  stakeholders,  capability  requirements,  system  requirements,  functions,  and 
operational  activities  for  the  WFTS  were  identified.  Most  importantly,  the  organizations 
and  stakeholders  determined  to  be  a  part  of  this  WFTS  were  identified  along  with  the 
operational  activities  they  are  assigned.  These  organizations  and  operational  activities 
allow  for  the  support,  conduct,  and  evaluation  of  webfires  training  during  the  basic, 
integrated,  and  sustainment  phases  of  the  OFRP  and  support  high-velocity  learning. 

a.  Recommendations 

OPNAV  N9I:  Provide  funding  and  acquisition  resources  to  support  the  United 
States  Fleet  Forces  (USFF)  Command,  numbered  fleets,  TTGs,  TYCOMs  and  NWDC  in 
the  following  tasks. 

USFF:  Direct  and  supervise  the  implementation  of  a  WFTS  and  direct  the 
Number  Fleets,  TTGs,  TYCOMS,  and  Warfare  Development  Centers  with  the  following 
tasks. 

Numbered  Fleets:  Begin  to  develop  and  implement  a  training  strategy  that 
includes  goals  and  objectives  to  train  CSG/ESGs  using  the  Webfires  Concepts  for 
specific  mission  sets  for  their  areas  of  responsibility.  Additionally,  this  should  be  a 
collaborative  effort  along  with  the  respective  TYCOMs,  TTGs,  and  NWDC. 

TTGs:  Collaborate  with  numbered  fleets  and  the  TYCOMs  in  order  to  help 
develop  training  goals  and  objectives  to  train  CSGs  and  ESGs  to  implement  a  webfires 
concept.  Additionally,  work  with  units,  numbered  fleets,  and  TYCOMs  to  help  create  a 
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training  scenario  database  that  will  allow  units  to  conduct  simulated  training  without 
having  to  coordinate  with  a  TTG  facility. 

TYCOMs:  Work  with  NWDC,  TTGs,  and  numbered  fleets  to  develop  training 
goals  and  objectives  to  train  CSGs  and  ESGs  to  implement  webfires  concepts. 

NWDC:  Work  with  all  warfare  development  centers  and  the  intelligence 
community  to  fully  develop  training,  tactics,  and  procedures  to  implement  webfires 
concepts. 

2.  Support  Training  of  CSG/ESG  Units  during  the  Basic,  Integrated, 
and  Sustainment  Phases  of  the  OFRP 

The  envisioned  training  system  is  only  a  relatively  small  part  of  the  total  training 
requirements  set  to  be  accomplished  during  the  OFRP.  To  be  effective  this  system,  must 
seamlessly  integrate  into  future  concept  of  operations  and  future  training  technologies 
should  support  this  integration  through  a  variety  of  methods. 

Throughout  the  different  phases  of  the  OFRP  we  envision  the  need  for  integrated 
training  to  occur  at  various  times  of  unit  readiness,  up  to  and  including  deployment.  In 
order  to  increase  the  number  of  quality  repetitions,  identified  as  a  current  limitation,  the 
need  to  link  shore  based  units  with  deployed  units  must  increase.  The  WFTS  has 
identified  technologies  and  organizations  that  support  this  possibility 

The  increase  of  integrated  training  within  the  future  envisioned  OFRP  training 
cycle  will  improve  training  quality,  retention  of  training  and  readiness.  The  ability  to 
work  with  actual  CSG/ESG  units  and  physical  contact  with  unit  hardware  will  produce 
positive  measurable  results  creating  stronger  team  practices. 

Along  with  increasing  quality,  the  system  should  provide  a  greater  in-depth 
feedback  system.  The  lessons  learned  data  from  each  event  can  be  fed  back  to  units  in  a 
shorter  period  of  time  to  improve  learning.  The  aviation  training  model  has  capitalized  on 
an  effective  feedback  system,  giving  clear  results  and  reinforcing  training  principles 
immediately  after  a  training  event,  which  from  research  is  the  greatest  opportunity  for 
learning.  It  is  envisioned  that  a  system  capitalizing  on  these  principles  could  be  expanded 
to  encompass  the  entire  CSG/ESG. 
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a.  Recommendation 

USFF,  with  funding  provided  by  OPNAV  N9I,  should  take  the  lead  on 
implementing  integration  by  directing  each  involved  TYCOM  and  introducing  the 
training  system.  Their  efforts  should  focus  on  integrating  compatible  components  along 
with  standardized  procedures  that  encourage  TYCOM  involvement  with  WFTS. 

3.  Leverage  High- Velocity  Learning  through  Current  and  Future 
Technology 

Adversary  warfighting  capabilities  are  continuing  to  grow  as  future  technology 
advancements  come  to  fruition  at  an  exponentially  faster  rate.  To  meet  these  continued 
threats,  it  is  imperative  that  U.S.  service  men  and  women  adapt  to  a  new  style  of  learning. 
This  style  is  high-velocity  learning,  which  challenges  warfighters  to  increase  the  speed  of 
the  current  learning  cycle.  In  a  culture  of  assessments  and  deep-rooted  traditions,  it  is 
ever  more  important  for  warfighters  to  take  charge  and  execute  centered  on  the 
commander’s  intent.  As  technology  continues  to  advance,  the  rate  of  data  collection  has 
increased  as  well.  By  leveraging  high-velocity  learning,  the  warfighter  is  better  able  to 
process  and  react  to  the  new  and  challenging  information  provided. 

The  key  to  providing  high-velocity  learning  is  increasing  repetition,  providing 
effective  feedback,  and  provide  quality  training.  The  future  WFTS  will  provide  high- 
velocity  learning  by  incorporating  feedback  data  collection,  simulations,  and  increased 
connectivity. 

•  Clear  data  collection,  processing,  and  distribution  requirements  must  be 
established 

•  Investment  into  being  able  to  provide  simulations  using  real  warfighting 
equipment  must  be  made  to  increase  the  quality  of  training 

•  IA  requirements,  network  topology,  and  communications  bandwidth 
limitations  must  be  addressed  to  allow  more  repetition  and  repeatability 

a.  Recommendation 

N9I  should  recommend  to  OPNAV  N2/6  they  work  with  warfare  development 
centers,  TYCOMs  and  the  intelligence  community  to  develop  a  link  that  supports  the 


149 


repetitive  ideals  of  high-velocity  learning.  This  link  should  reinforce  learning  by 
providing  feedback  at  a  sufficient  rate,  such  that  lessons  learned  can  be  reemployed  in 
near  real-time. 

4.  System  Will  Be  Cost-Effective 

Looking  into  the  future,  a  quantitative  cost  effectiveness  assessment  is  difficult  to 
assemble  at  this  time.  After  the  2025-2030  technology  has  matured,  the  proposed  WFTS 
solution  could  be  better  estimated.  The  cost  for  the  risk/reward  and  the  associated 
technology  development  and  implementation  should  change  the  way  learning  and 
readiness  is  accomplished  in  the  fleet  of  tomorrow. 

a.  Recommendation 

OPNAV-N9I  engage  the  civilian  technology  sector  to  aid  in  the  development  of 
simulators  and  networking  infrastructure  capable  of  replacing  underway  combat  training 
exercises  with  in-port  simulations  of  equal  or  greater  fidelity.  It  is  not  recommended  to 
replace  all  underway  combat  training  exercises,  but  replacing  even  a  small  amount  of  the 
underway  training  time  is  expected  to  have  considerable  cost  savings  due  to  the  high 
costs  associated  with  fuel  consumption  and  logistics  to  get  a  unit  underway.  The  same 
recommendation  holds  for  reduced  flight  operations  and  increased  high  fidelity  flight 
simulations. 

It  is  understood  that  there  is  no  substitute  for  training  through  actual  system 
operation,  but  when  actual  system  operation  is  so  costly  or  logistically  complex  that  it 
limits  training  exercises,  there  is  some  benefit  to  supplementing  a  portion  of  the  training 
through  actual  system  operations  with  the  more  cost-effective  and  repetitive  training  that 
simulation  can  bring. 

C.  FURTHER  RESEARCH 

The  following  item  are  recommended  research  topics  that  will  complement  the 
recommendations  contained  herein,  but  were  judged  to  be  outside  the  scope  of  this  report 


150 


1.  Cyber  Domain 

During  the  capstone  project,  the  team  focused  on  developing  a  training 
architecture  for  the  webfires  system.  The  cyber  domain  was  considered  outside  the  scope 
of  the  research.  The  successful  employment  of  WFTS  will  reply  on  further  research  in  the 
cyber  domain.  The  team  recommends  two  specific  areas  of  cyber  domain  for  further 
research:  cyber  security  and  information  assurance.  Since  the  WFTS  is  network  centric, 
it  relies  heavily  on  external  communication  links  to  share  targeting  data.  Future  research 
should  focus  on  how  to  defend  the  WFTS  and  its  associated  networks  from  cyber-attacks. 
In  addition,  most  of  the  current  Navy  and  Marine  Corps  training  systems  are  stovepipe 
systems.  These  training  systems  are  built  by  various  contractors  and  have  different 
system  classifications.  They  do  not  integrate  and  communicate  with  one  another.  Future 
research  should  focus  on  information  assurance  to  support  systems  integration  and  data 
protection. 

2.  Communication  Networks 

The  WFTS  will  rely  on  an  exceptionally  high  level  of  communications.  Further 
research  should  focus  on  the  entire  electromagnetic  spectrum  to  support  communications. 
Having  a  good  understanding  of  all  the  frequencies  will  provide  a  greater  insight  into  all 
the  available  means  of  communication  for  the  WFTS  and  identify  the  communication 
links  that  would  optimally  support  WFTS.  These  communication  links  could  potentially 
increase  overall  network  readiness  and  training  effectiveness. 

One  concept  for  communication  speculated  during  the  research  was  the  concept 
of  a  Link-T.  Similar  to  the  concept  of  Link-16  and  CEC,  Link-T  would  be  a  dedicated 
communication  network  to  execute  the  WFTS.  This  Link-T  network  would  be  used  to 
transmit  data  for  the  use  of  simulation,  simulation  control  data,  feedback  data,  and  other 
forms  of  data  or  information  used  to  conduct  training  through  the  various  phases  of 
training. 
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3.  Artificial  Intelligence  and  Artificial  Reality 

In  the  realm  of  AI  and  AR,  this  project  was  required  to  assume  optimal  and 
streamlined  engagement  of  computer  systems  to  contribute  to  robust  training 
environments.  When  it  comes  to  computing  the  decisions  and  displaying  the  reactions  of 
near-peer  threats  based  on  an  independent  variable  of  blue  force  actions  and  reactions, 
extensive  research  will  be  required  into  topics  such  as  the  conceptual  and  computer 
architecture,  software  programming  requirements,  hardware  capabilities,  and  proprietary 
algorithm  classification. 

Additionally,  the  extensive  infrastructure  requirements  that  are  needed  to  augment 
reality  on  actual  shipboard  equipment  or  in  a  shore -based  simulator  facility  pose  a 
significant  design  problem.  Further  studies  on  the  locations,  costs,  impacts  to  the  OFRP 
for  vessels  that  are  being  retrofitted/upgraded  to  support  artificial  reality,  timeline  for 
implementation,  and  similar  information  would  be  needed. 

4.  Continue  Architecture/Design  Including  Development  of  an  NTSP 

Based  on  the  tasking  statement,  the  team’s  interpretation  of  that  statement,  and  the 
generation  of  the  unique  problem  statement,  the  team  delivered  a  conceptual  architecture 
for  development  of  a  WFTS.  The  process  essentially  paralleled  a  Material  Solutions 
Analysis  phase  of  the  DOD  Acquisition  process  and  would  provide  a  blueprint  for  a  DOD 
Program  Manager  to  enter  Milestone  A  as  seen  in  Figure  59. 
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Figure  59.  DOD  Acquisitions  Process. 
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The  team  recommends  the  Navy  assign  further  research  to  continue  through  the 
DOD  Acquisition  process,  beginning  with  production  of  a  Naval  Training  Systems  Plan 
(NTSP).  This  would  be  in  accordance  with  OPNAV  1500.76C,  which  states:  “Programs 
designated  with  a  training  KPP  [key  performance  parameter]  are  required  to  produce  a 
preliminary  NTSP  at  [Milestone- A]”  (Chief  of  Naval  Operations  2013). 

Finally,  as  technologies  advance  and  the  webfires  concept  comes  to  fruition,  the 
team  recommends  further  research  on  major  parts  of  the  Technology  Maturation  &  Risk 
Reduction  phase  seen  in  Figure  59.  to  advance  toward  requirements  needed  for  a 
Milestone  B  decision.  Such  topics  include  establishment  of  a  Test  and  Evaluation  Master 
Plan,  Risk  Assessment  program,  and  technology  readiness  assessment  (AcqNotes  2017b). 

5.  Acquisitions  Stovepiping 

To  increase  the  cross-domain  and  cross-platform  capabilities  and  trainings,  further 
research  should  focus  on  system  integration  during  the  acquisition  process.  By 
emphasizing  system  integration  early  in  the  acquisition  process,  the  SME  can  identify 
essential  system  integration  requirements  for  the  developing  systems.  Understanding 
these  system  integration  requirements  would  significantly  increase  interoperability 
between  the  developing  systems  and  the  established  systems.  This  will  result  in  increased 
integration  and  readiness  of  the  webfires  system  and  the  training  system. 

6.  Face-to-Face  Briefing/Debriefing 

To  help  increase  webfires  training  effectiveness,  further  research  needs  to  focus 
on  face-to-face  briefing  and  other  means  of  briefing.  The  face-to-face  debriefing  process 
involves  all  the  training  participants  meeting  together  immediately  after  the  training  event 
for  a  final  debrief.  Being  able  to  meet  face  to  face  to  review  the  previous  training  event 
can  potentially  increase  teamwork,  quality  of  feedback,  and  training  fidelity.  While  face- 
to-face  debriefing  is  valuable,  it  is  not  always  practical  out  at  sea.  Further  research  should 
focus  on  other  means  of  briefing,  such  as  video  teleconference  and  virtual 
communications . 
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7.  Helping  of  Certification  and  Evaluation 

The  team  developed  a  WFTS  that  provides  training  data  for  evaluation  and 
certification.  Further  research  needs  to  focus  on  determining  what  data  is  required  by 
various  stakeholders  and  how  to  utilize  these  training  data.  Being  able  to  utilize  these 
training  data  effectively  can  potentially  increase  training  effectiveness,  reduce  evaluation 
and  certification  time,  and  update  a  unit’s  readiness. 

8.  Warfare  Subject  Matter  Experts 

Based  on  stakeholder  feedback,  the  team  found  implementing  SMEs  has  long 
been  recognized  in  the  aviation  community  as  a  best  practice.  The  aviation  community 
retained  superior  tactical  talent  for  considerable  time  within  an  operational  environment, 
allowing  for  quality  training  that  was  better  retained  by  the  warfighters.  The  surface 
warfare  community  has  begun  to  implement  procedures  that  have  been  modeled  after 
these  best  practices  with  positive  results.  As  the  Navy’s  mission  begins  implementing 
more  cross-domain  operations,  further  research  will  be  needed  to  understand  how  all 
communities  and  platforms  can  produce  a  cadre  of  SMEs,  and  how  to  best  employ  their 
time  and  talent  into  maximizing  benefits  from  their  tactical  efficiencies. 
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APPENDIX  A.  OFFICIAL  TASKING  STATEMENT 


NAVAL 


POJTCBAOUATS 

SCHOOL 


2  Aug  16 


Memorandum  for  Systems  Engineering  Analysis  Cohort  2$  (SEA25) 

Subj:  FY2017  SEA25  Capstone  Projects:  Tasking  and  Timelines 
Enclosures: 

Tab  A:  Developing  warlighting  training  to  leverage  the  web  fires  concept  and  technology 
Tab  B  NPS  Warfare  Innovation  Continuum  “Strengthen  naval  power  at  and  from  the  sea" 

Tab  C:  IRB  Student  Checklist 

1 .  This  memorandum  provides  the  FY20I7  guidance  for  the  conduct  of  the  Systems 
Engineering  Analysis  (SEA)  integrated  project,  which  is  required  as  partial  fulfillment  for  the 
SEA  degree.  SEA  students  will  deliver  completed  project  teports  and  final  briefing  materials 
to  faculty  advisors  in  accordance  with  the  following  plan  and  milestones.  Each  group  will: 

a.  Develop  project  proposals  and  management  plans  during  the  Fall  Quarter  A Y201 7 
These  proposals  and  plans  will  serve  to  focus  mitral  research  and  analysis.  These 
plans  will  be  reviewed  and  updated  frequently  as  research  progresses 
b  Conduct  project  reviews  approximately  every  six  weeks,  finishing  with  a  final  brief  to 
interested  stakeholders  on  and  off  campus. 

C.  Assign  a  report  lead  from  each  team.  Work  closely  with  faculty  advisors  to  prepare 
the  final  reports  for  faculty  advisor  signature  by  four  work-weeks  before  graduation 
Tile  final  reports  are  then  due  to  the  SEA  chairman  one  week  later,  and  to  the 
Operations  Research  and  Systems  Engineering  department  chairmen  one  week  before 
graduation. 

2.  SEA  students  are  expected  to  identity  and  integrate  students  and  (acuity  from  across  the 
campus  -  and  also  from  outside  NPS  -  to  participate  directly  in  the  project  or  to  provide 
source  documents,  technical  know  ledge  and  insights,  and  knowledge  of  evolving 
requirements,  capabilities,  and  systems.  This  participation  could  include  students  who  would 
join  project  groups,  students  doing  related  individual  thesis  topics  from  TSSE.  TDSI,  OR,  IS 
or  SF.;  faculty  inside  or  outside  NPS  who  have  expertise  related  to  the  project;  and 
appropriately  engaged  government  agencies  and  industry  developers  It  is  live  students' 
responsibility  to  integrate  the  efforts  of  outside  participants  in  the  projects  Faculty  adv  isors 
and  the  SEA  Chair  will,  of  course,  significantly  assist  in  these  efforts. 

3.  Prior  to  commencing  the  formalized  systems  engineering  and  analysis  process  including 
stakeholder  analysis,  the  SEA  team  will  consult  with  Dr.  Larry  Shattuck,  Chairman  of  the 
NPS  Institutional  Review  Board  and  submit  to  him  TAB  A,  a  general  description  of  the 
team's  systems  and  analytical  approach  to  address  the  tasking,  a  completed  IRB  student 
research  form  (Tab  C)  and  n  list  of  candidate  questions  fur  stakeholders  to  review.  Jhe 
intent  is  to  ensure  questions  are  oriented  about  the  “what"  of  the  systems  and  not  about  the 
"who”  of  the  stakeholder. 
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4  The  analysis  will  employ  the  systems  engineering  and  operations  research  methodologies 
presented  in  class  work  and  front  the  project  advisors  The  role  of  the  SEA  students  is  that  of 
the  lead  project  systems  engineering  team,  working  closely  with  other  members  of  the  project 
engineering  teams  from  TDSI  and  other  campus  curricula  SEA  students  will  he  expected  to 
define  the  functions  and  performance  of  systems,  develop  alternative  architectures  to  meet 
those  functions,  and  evaluate  the  alternative  architectures  for  performance  and  cost  In 
executing  these  tasks,  students  will  be  defining  and  understanding  the  overall  project 
requirements,  recognizing  that  the  definition  process  is  iterative  and  will  evolve  as  the  project 
progresses. 

5.  Grades  are  assigned  to  the  participants  in  these  projects.  Although  work  is  performed  as  purl 
of  a  learn,  individual  performance  will  be  the  basis  for  this  evaluation.  Successful  completion 
and  documentation  of  the  project  is  a  degree  requirement 

6.  The  SEA25  project  will  build  on.  possibly  challenge,  but  not  replicate,  other  DOD  and  SEA 
projects  SEA25  will  exnmine  virtual  environment  technologies  for  potential  contributions  to 
establish  effective  training  in  web  fires  tactics  and  employment.  SEA25  will  coordinate 
their  study  efforts,  participate  and  occupy  leadership  roles  in  other  FYI6/I7  efforts  at  NPS 
aimed  at  strengthening  naval  power  at  and  from  the  sea.  These  activities,  coordinated  by  the 
Chau  of  Systems  Engineering  Analysts  are  described  in  Tab  B. 


Jeffrey  E.  Kline 

Chairman,  Systems  Engineering  Analysis  Curriculum 
Professor  of  Practice,  Operations  Research 
Naval  Postgraduate  School 
Monterey.  CA  93908 


Distribution  SEA2S  students.  Profs.  Hughes,  Jacobs.  Giachetti.  Hatch.  Whitcomb,  Sicvens. 
Solitario.  Kline,  Harney,  Papoulias,  Potter,  Boger,  BrutTman.  Buettner,  McDowell,  President 
Route;  Provost  llensler.  Deans  Wirtz,  Scandrett.  McCormick,  Paduan,  and  Moses,  CAPT  Daniel 
Verheul.  Dr.  Shattuck.  LCDR  Naccarato,  RDML  Williams,  RADM  Ellis,  Mr  Paul  Lluv 
tOPNAV  N9B1.  RADM  Fantn  (OPNAV  N9I\  Mr.  Steve  Dreiss  (OPNAV  N9IB).  Mr.  Mike 
Novak  (OPNAV  N99B),  Mr.  Chuck  Werchado  (N8IB).  and  Ms.  Kathie  Cain 
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TAB  A 


SEA  25  I  asking 

Developing  war-fighting  training  to  leverage  web  fire*  cunctfils  and  technologies. 

Design  a  fled  system  of  systems  and  concept  of  operations  for  employment  of  a  cost  effective 
training  system  capable  of  preparing  naval  warfighters  to  employ  and  leverage  the  web  fires 
concepts  and  technologies  in  the  2025-2030  timeframe.  Consider  training  across  warfare 
cpm-ialriM  nnrl  mission*  Prsnrtnrt  research  tn  provide  n  solid  foundation  of  knowledge 
requirements  for  a  web  fires  fleet  concept.  Then  complete  a  gap  analysis  by  comparing  current 
fleet  training  with  the  required  training  to  leverage  cross  domain  and  cross-platfotm  capabilities 
in  a  war  fighting  environment  Scan  for  current  examples  of  cross-domain  training  and  current 
training  simulation  from  DoD  and  industry.  Develop  a  system  architecture  addressing 
responsible  command,  training  requirements,  training  and  exercise  venues,  and  training 
participants  to  fill  discovered  gap*  in  meeting  the  knowledge  requirements.  Assess  tbc  proposed 
system  against  die  principles  of  high  velocity  learning  found  in  the  CNO's  "A  Design  for 
Maintaining  Maritime  Superiority” 


Advisors; 

Senior  Lecturer  Bill  Hatch.  Graduate  School  of  Business  and  Public  Policy 

TBD.  Systems  Engineering  Deportment 

Dr.  Michael  Atkinson,  Operation*  Research  Deportment 
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APPENDIX  B.  OFRP  OPERATIONAL  ACTIVITY  SUMMARY 

TABLE 


OA# 

Operational 

Activity 

Performer 

Input 

Output 

OA.  1.1 

Manage 

Sustainment 

Training 

#  Fleet 

Commander 

Sustainment 

Training  Feedback 

Unit  Sustainment 
Training  Status 

Sustainment 

Training 

Requirements 

OA.2.1 

Manage 

Integrated 

Training 

#  Fleet 

Commander 

Unit  Integrated 
Training  Status 

Integrated  Training/ 

Certification 

Requirements 

OA.  1.2 

Monitor  Unit 
Status 

(Sustainment) 

CSG/ESG 

Commander 

Sustainment 

Training  Feedback 

Sustainment 

Training 

Requirements 

Unit  Sustainment 
Training  Status 

OA.1.3 

Direct  Units 
(Sustainment) 

CSG/ESG 

Commander 

Unit  Direction 
(Sustainment) 

OA.  1.4 

Receive  Training 

Requirements 

(Sustainment) 

CSG/ESG  Unit 

Sustainment 

Training 

Requirements 

OA.1.5 

Conduct 

Sustainment 

Training 

CSG/ESG  Unit 

Unit  Direction 
(Sustainment) 

OA.1.6 

Document 

Sustainment 

Training 

CSG/ESG  Unit 

Unit  Sustainment 
Training  Status 

OA.  1.7 

Provide 

Sustainment 

Training 

Feedback 

CSG/ESG  Unit 

Sustainment 

Training  Feedback 

OA.2.2 

Facilitate 

Integrated 

Training 

TACTRAGROUP 

Integrated  Training/ 

Certification 

Requirements 

Integrated  Training 

OA.3.1 

Manage  Unit 
Level  Training 

TYCOM 

Unit  Level  Training 
Feedback 

Unit  Level  Training 
Status 

Unit  Level  Training/ 

Certification 

Requirements 
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OA# 

Operational 

Activity 

Performer 

Input 

Output 

OA.3.2 

Manage  WDCs 

TYCOM 

Unit  Level  Training 
Feedback 

Doctrine  Guidance 

Procedure  Guidance 

OA.2.8 

Receive 

Evaluation 

Requirements 

(Integrated) 

Certification 

Programs 

Integrated  Training/ 

Certification 

Requirements 

OA.2.9 

Evaluate  Units 
(Integrated) 

Certification 

Programs 

Integrated  Unit 
Performance 

Unit  Integrated 
Training  Status 

OA.3.3 

Receive  Unit 
Level  Evaluation 
Requirements 

Certification 

Programs 

Unit  Level 

Training/ 

Certification 

Requirements 

OA.3.4 

Evaluate  Unit 
Level 

Performance 

Certification 

Programs 

Unit  Level 
Performance 

Unit  Level  Training 
Status 

OA.2.3 

Monitor  Unit 

Status 

(Integrated) 

CSG/ESG 

Commander 

Integrated  Training 
Feedback 

Integrated  Training/ 

Certification 

Requirements 

Integrated  Unit 
Performance 

Unit  Integrated 
Training  Status 

OA.2.4 

Direct  Units 
(Integrated) 

CSG/ESG 

Commander 

Unit  Direction 
(Integrated) 

OA.2.10 

Receive  Training 

Requirements 

(Integrated) 

CSG/ESG  Unit 

Integrated  Training/ 

Certification 

Requirements 

OA.2.11 

Conduct 

Integrated 

Training 

CSG/ESG  Unit 

Integrated  Training 
Unit  Direction 
(Integrated) 

OA.2.12 

Document 

Training 

(Integrated) 

CSG/ESG  Unit 

Integrated  Unit 
Performance 

OA.2.13 

Provide 

Integrated 

Training 

Feedback 

CSG/ESG  Unit 

Integrated  Training 
Feedback 
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OA# 

Operational 

Activity 

Performer 

Input 

Output 

OA.3.8 

Receive  Training 
Requirements 
(Unit  Level) 

CSG/ESG  Unit 

Doctrine  Guidance 

Procedure  Guidance 

Unit  Level  Training/ 

Certification 

Requirements 

OA.3.9 

Conduct  Unit 
Training 

CSG/ESG  Unit 

Unit  Level  Training 
(Through  Facilities) 

OA.3.10 

Document  Unit 
Level  Training 

CSG/ESG  Unit 

Unit  Level 
Performance 

OA.3.11 

Provide  Unit 

Level  Training 
Feedback 

CSG/ESG  Unit 

Unit  Level  Training 
Feedback 

OA.2.5 

Receive 

Integrated 

Training 

Requirements 

Fleet  Level 
Training  Facility 

Integrated  Training/ 

Certification 

Requirements 

OA.2.6 

Provide 

Interactive 

Training 

(Integrated) 

Fleet  Level 
Training  Facility 

Integrated  Training 

OA.2.7 

Evaluate 

Interactive 

Training 

(Integrated) 

Fleet  Level 
Training  Facility 

Integrated  Unit 
Performance 

Integrated  Training 
Feedback 

Unit  Integrated 
Training  Status 

OA.3.5 

Receive  Unit 

Level  Training 
Requirements 

Fleet  Level 
Training  Facility 

Unit  Level  Training/ 

Certification 

Requirements 

OA.3.6 

Provide 

Interactive  Unit 
Level  Training 

Fleet  Level 
Training  Facility 

Unit  Level  Training 
(Through  Facilities) 

OA.3.7 

Evaluate  Unit 
Level  Interactive 
Training 

Fleet  Level 
Training  Facility 

Unit  Level 
Performance 

Unit  Level  Training 
Status 
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APPENDIX  C.  COMPONENT  TRADE-OFF  ANALYSIS  SUMMARY 


Category 

Advantages 

Disadvantages 

Provide  Simulations 

Artificial 

Intelligence 

-  Potential  to  Mimic  Tactical 
Fidelity  of  Manual  Control 

-  Not  Relying  on  SME  to  Run 
Scenarios 

-  Expensive  to  Program  and 
Develop 

-  Time  Intensive  to  Develop 

Manual 

-  Realistic  Tactics 

-  Highest  Fidelity  Tactics  (Real 
Time  Responses  and  Delays) 

-  High  SME  Demand 

-  Labor  Intensive 

-  Time  Consuming 

Preprogrammed 

-  Low  Cost 

-  High  Repetition 

-  Range  Greatly  in  Complexity 

-  Easily  Tailored  to  Meet 

Training  Objectives 

-  Lowest  Fidelity 

-  Potentially  “Game”  the 
Scenario  after  a  Few 
Repetitions 

Communicate 

Hard  Wire  (LAN 
Line) 

-  High  Data  Rate 

-  Cheap  and  Simple  over  Short 
Distances 

-  Does  Not  Have  At-Sea 
Capability 

-  Expensive  over  Long 
Distances 

Over  The 

Horizon  (OTH) 

-  Greater  Ranges  than  LOS 
Communications 

-  Lowest  Data  Rate 
-HF  possible  RADHAZ 

Line  Of  Sight 
(LOS) 

-  Low  cost 

-  Not  Relying  on  SATCOMS 
-Moderate  to  high  data  rates 

-  No  Over  the  Horizon 
Capability 

-  Point  to  Point  LOS  between 
Ships  in  Port  Might  be  A 
RADHAZ 

Satellite  Corns 

-Cover  Great  Ranges 
-Moderate  Data  Rates 

-High  Cost 

Stimulate  Units 

Non-Console 

-  Low  Cost 

-  Great  for  Individual  Training 

-  Lowest  Fidelity 

Simulated 

Console 

-  Great  for  Unit  Training 

-  Available  to  Multiple  Units 

-  Medium  to  Low  Fidelity 

-  Does  Not  Train  to 

Equipment  Operation 

Actual  Console 

-  Highest  Fidelity 

-  Expensive  Simulators/ 
Facilities 

V_xV_/JLJLLJL  UJ 

Simulati 

Central  Control 

-  Unity  of  Command 

-  SME  Only  Needed  at  Central 
Location 

-  Single  Point  of  Failure 

-  Potentially  Limited 

Repetition 
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Local  Control 

-  Not  Required  Central  Control 

-  Unity  of  Command 

-  Potentially  Increased  Repetition 

-  Single  Point  of  Failure 

Unit  Control 

-  All  Webfires  Capable  Units 

Can  Control  Simulation 

-  Increases  Repetition 

-  Not  Relying  on  Central  or 

Local  node 

-  Difficult  to  Manage  Large 
Training  Events 

Interface  with  Network 

Star  Network 
(Shore-Side) 

-  Central  Hub  Controls  and 
Monitors  All  Units 

-  Easy  to  Connect  and 

Disconnect  from  Central  Hub 

-  Single  Point  of  Failure 

-  All  Non-Central  Units  Must 
Connect  to  a  Central  Hub 

Multiple-Stars 
(Shore  and  Sea) 

-  Enable  More  Units  to  Joint 
Training 

-  Easy  to  Connect  and 

Disconnect  from  Central  Hub 

-  Single  Point  of  Failure 

-  All  Non-Central  Units  Must 
Connect  to  a  Central  Hub 

Mesh  Network 

-  Very  Reliable 

-  Expensive 

-  Very  Complicated 

Store  Data 

Centralized 

-  Whole  Picture  Data 

-  Highly  Accessible 

-  Single  Point  of  Failure 

Local 

-  Units  Can  Recall  Own  Data 
Independent  of  Networks 

-  Must  Have  Storage 

Capability  at  Each  Unit 

-  Partial  Picture  Data 

Portable  Media 

-  Low  Cost 

-  Convenient 

-  Must  Have  Storage 

Capability  at  Each  Unit 

-  Time  Delay  to  Transfer 

Media  from  Portable  Storage 
to  Destination 

-  Partial  Picture  Data 
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APPENDIX  D.  WEBFIRES  TRAINING  SYSTEM  ARCHITECTURE 


A.  OPERATIONAL  ITEMS  TRANSFER  MATRIX 


Nodes 

Connected  To 

Operational  Items 
Transferred 

Description 

#Fleet 

Unit/Simulator 

Control  &  Data  &  Scenario 

Data  (Feedback  Data)  will  be 
passed  from  Units  and 

Simulators  for  the  purpose  of 
evaluation  or  certifications. 

Scenarios  and  control  of  those 
scenarios  will  be  passed  to  Units 
and  Simulators  from  the  #Fleet, 
TYCOM,  TACTRAGRU,  or 
CSG/ESG  CMDR. 

TYCOM 

Unit/Simulator 

Control  &  Data  &  Scenario 

TACTRAGRU 

Unit/Simulator 

Control  &  Data  &  Scenario 

CSG/ESG  CMDR 
Unit/Simulator 

Control  &  Data  &  Scenario 

Intel  Community 
TACTRAGRU 

Enemy  Capabilities/Tactics 

The  Intelligence  Community 
will  update  and  pass  the  enemies 
capabilities  and  tactics  to  the 
organizations  that  are  involved 
in  running  the  Units/Simulators 
as  well  as  the  Units/Simulators 
themselves. 

#Fleet 

Intel  Community 

Enemy  Capabilities/Tactics 

Intel  Community 
Unit/Simulator 

Enemy  Capabilities/Tactics 

Intel  Community 
TYCOM 

Enemy  Capabilities/Tactics 

CSG/ESG  CMDR 
Intel  Community 

Enemy  Capabilities/Tactics 

CSG-4/15 

Unit/Simulator 

Data 

Data  (Feedback  Data)  will  be 
passed  to  NWDC  for  use  to 
update  TTPs.  Additionally,  data 
will  be  used  for  evaluation  or 
certification  by  the  CSG-4/15 
responsible  for  certifying  a 

Strike  Group  for  deployment. 

NWDC 

Unit/Simulator 

Data 

#Fleet 

TYCOM 

Training  Objectives 

The  #Fleets  and  the  TYCOMs 
will  pass  training  objectives  to 
the  organizations  that  are 
responsible  for  establishing 
training  scenarios  and  training 
Units  and  Strike  Groups. 

#Fleet 

CSG/ESG  CMDR 

Training  Objectives 

TACTRAGRU 

TYCOM 

Training  Objectives 

CSG/ESG  CMDR 
TYCOM 

Training  Objectives 

#Fleet 

Training  Objectives 

165 


Nodes 

Connected  To 

Operational  Items 
Transferred 

Description 

TACTRAGRU 

#Fleet 

UP 

NWDC  will  provide  Webfires 

NWDC 

TTPs  that  can  be  used  to 

NWDC 

UP 

establish  Training  Objectives  for 

TYCOM 

Units  and  Strike  Groups. 
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B. 


WEBFIRES  TRAINING  SYSTEM  CV-6  TABLE 


Cap  Req# 

Capability 

Requirements 

Operational  Activities 

CapReq.l 

Repetition 

CapReq.1.1 

Provide  Training 
Scenarios 

OA.1.1  Collect  Intel  on  Enemy 

OA.1.4  Provide  Multi-Unit  (Cross  Domain)  Scenarios 
OA.1.6  Establish  Multi-Unit  Scenarios 

OA.1.7  Establish  Unit  Scenarios 

CapReq.l. 2 

Run  simulations 
independently 
between  units  and 
simulators 

OA.2.1  Facilitate  Fleet  Scenarios 

OA.2.2  Facilitate  (Cross  Domain)  Scenarios 

OA.2.3  Facilitate  Scenarios 

OA.2.4  Facilitate  CSG/ESG  Scenarios 

OA.2.5  Create/Modify/Receive  Scenarios 

OA.2.6  Conduct  In-port  Unit  Training 

OA.2.7  Conduct  At-Sea  Unit  Training 

OA.2.8  Conduct  At-Sea  Multi-Unit  Training 

OA.2.9  Conduct  In-Port  Multi-Unit  Training 

OA.2.10  Conduct  Hybrid  Training 

CapReq.l. 3 

Train  with  limited 
communications 

OA.2.1  Facilitate  Fleet  Scenarios 

OA.2.2  Facilitate  (Cross  Domain)  Scenarios 

OA.2.3  Facilitate  Scenarios 

OA.2.4  Facilitate  CSG/ESG  Scenarios 

OA.2.5  Create/Modify/Receive  Scenarios 

OA.2.6  Conduct  In-port  Unit  Training 

OA.2.7  Conduct  At-Sea  Unit  Training 

OA.2.8  Conduct  At-Sea  Multi-Unit  Training 

OA.2.9  Conduct  In-Port  Multi-Unit  Training 

OA.2.10  Conduct  Hybrid  Training 

CapReq.2 

Feedback 

CapReq.2.1 

Provide  Data  for 
certification  and 
evaluation 

OA.2.11  Produce  Feedback 

OA.3.1  Evaluate  Fleet 

OA.3.2  Certify  ESG/CSG  for  Deployment 

OA.3.3  Certify  For  Entry  into  Advanced  Phase 

OA.3.4  Evaluate  Type  Training 

OA.3.6  Evaluate  CSG/ESG 

CapReq.2. 2 

Provide  Data  to 
update  TTP 

OA.2.11  Produce  Feedback 

OA.3.5  Evaluate  Doctrine/Tactics/Procedures 

CapReq.3 

Integration 

OA.2.6  Conduct  In-port  Unit  Training 

OA.2.7  Conduct  At-Sea  Unit  Training 

OA.2.8  Conduct  At-Sea  Multi-Unit  Training 

OA.2.9  Conduct  In-Port  Multi-Unit  Training 

OA.2.10  Conduct  Hybrid  Training 

CapReq.4 

Webfires  Concept  Training 

167 


Cap  Req# 

Capability 

Requirements 

Operational  Activities 

CapReq.4. 1 

In-port  and  At-sea 

OA.1.8  Create  Doctrine/Tactics/Procedures 

OA.2.6  Conduct  In-port  Unit  Training 

OA.2.7  Conduct  At-Sea  Unit  Training 

OA.2.8  Conduct  At-Sea  Multi-Unit  Training 

OA.2.9  Conduct  In-Port  Multi-Unit  Training 

OA.2.10  Conduct  Hybrid  Training 

CapReq.4.2 

Multi-Unit  and 

Unit  Training 

OA.1.8  Create  Doctrine/Tactics/Procedures 

OA.2.8  Conduct  At-Sea  Multi-Unit  Training 

OA.2.9  Conduct  In-Port  Multi-Unit  Training 

OA.2.10  Conduct  Hybrid  Training 

CapReq.4. 3 

OFRP 

OA.1.2  Establish  Fleet  Training  Objectives 

OA.1.3  Establish  Fleet  Scenarios 

OA.1.4  Provide  Multi-Unit  (Cross  Domain)  Scenarios 
OA.1.5  Establish  Type  Training  Objectives 

OA.1.6  Establish  Multi-Unit  Scenarios 

OA.1.7  Establish  Unit  Scenarios 

OA.1.8  Create  Doctrine/Tactics/Procedures 

OA.1.9  Establish  CSG/ESG  Scenarios 

OA.2.1  Facilitate  Fleet  Scenarios 

OA.2.2  Facilitate  (Cross  Domain)  Scenarios 

OA.2.3  Facilitate  Scenarios 

OA.2.4  Facilitate  CSG/ESG  Scenarios 

OA.2.5  Create/Modify/Receive  Scenarios 
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c. 


WEBFIRES  TRAINING  SYSTEM  SY-5A  TABLE 


OA# 

Operational  Activity 

Implemented  By 

OA.l 

Support  Training 

OA.1.1 

Collect  Intel  on  Enemy 

No  Function  to  support  this 
operational  activity 

OA.1.2 

Establish  Fleet  Training 
Objectives 

No  Function  to  support  this 
operational  activity 

OA.1.3 

Establish  Fleet  Scenarios 

F.1.1  Create  Simulation 

F.1.2  Store  Simulation 

F.1.3  Modify  Existing  Simulation 
F.1.4  Receive  Intel  Updates 

OA.1.4 

Provide  Multi-Unit  (Cross 
Domain)  Scenarios 

F.1.1  Create  Simulation 

F.1.2  Store  Simulation 

F.1.3  Modify  Existing  Simulation 
F.1.4  Receive  Intel  Updates 

OA.1.5 

Establish  Type  Training 
Objectives 

No  Function  to  support  this 
operational  activity 

OA.1.6 

Establish  Multi-Unit  Scenarios 

F.1.1  Create  Simulation 

F.1.2  Store  Simulation 

F.1.3  Modify  Existing  Simulation 
F.1.4  Receive  Intel  Updates 

OA.1.7 

Establish  Unit  Scenarios 

F.1.1  Create  Simulation 

F.1.2  Store  Simulation 

F.1.3  Modify  Existing  Simulation 
F.1.4  Receive  Intel  Updates 

OA.1.8 

Create  Doctrine/Tactics/ 
Procedures 

No  Function  to  support  this 
operational  activity 

OA.1.9 

Establish  CSG/ESG  Scenarios 

F.1.1  Create  Simulation 

F.1.2  Store  Simulation 

F.1.3  Modify  Existing  Simulation 
F.1.4  Receive  Intel  Updates 

OA.2 

Conduct  Training 

OA.2.1 

Facilitate  Fleet  Scenarios 

F.1.5  Receive  Simulations 

F.3.3  Control  Simulations 

F.4. 1  Interface  with  Human 

F.4.2  Interface  With  System 

OA.2. 2 

Facilitate  (Cross  Domain) 
Scenarios 

F.1.5  Receive  Simulations 

F.3.3  Control  Simulations 

F.4. 1  Interface  with  Human 

F.4.2  Interface  With  System 
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OA# 

Operational  Activity 

Implemented  By 

OA.2.3 

Facilitate  Scenarios 

F.l. 5  Receive  Simulations 

F.3.3  Control  Simulations 

F.4. 1  Interface  with  Human 

F.4.2  Interface  With  System 

OA.2.4 

Facilitate  CSG/ESG  Scenarios 

F.1.5  Receive  Simulations 

F.3.3  Control  Simulations 

F.4. 1  Interface  with  Human 

F.4.2  Interface  With  System 

OA.2.5 

Create/Modify /Receive 

Scenarios 

F.1.1  Create  Simulation 

F.l. 2  Store  Simulation 

F.1.3  Modify  Existing  Simulation 

F.l. 4  Receive  Intel  Updates 

F.1.5  Receive  Simulations 

F.2.3  Transmit  Simulations 

OA.2.6 

Conduct  In-port  Unit  Training 

F.2.2  Transmit  Voice 

F.3.1  Stimulate  Sensors  on  Units 

F.3.2  Stimulate  Simulators 

F.3.3  Control  Simulations 

F.4. 1  Interface  with  Human 

F.4.2  Interface  With  System 

OA.2.7 

Conduct  At-Sea  Unit  Training 

F.2.2  Transmit  Voice 

F.3.1  Stimulate  Sensors  on  Units 

F.3.2  Stimulate  Simulators 

F.3.3  Control  Simulations 

F.4. 1  Interface  with  Human 

F.4.2  Interface  With  System 

OA.2.8 

Conduct  At-Sea  Multi-Unit 
Training 

F.2.2  Transmit  Voice 

F.3.1  Stimulate  Sensors  on  Units 

F.3.2  Stimulate  Simulators 

F.3.3  Control  Simulations 

F.4. 1  Interface  with  Human 

F.4.2  Interface  With  System 

OA.2.9 

Conduct  In-Port  Multi-Unit 
Training 

F.2.2  Transmit  Voice 

F.3.1  Stimulate  Sensors  on  Units 

F.3.2  Stimulate  Simulators 

F.3.3  Control  Simulations 

F.4. 1  Interface  with  Human 

F.4.2  Interface  With  System 
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OA# 

Operational  Activity 

Implemented  By 

OA.2.10 

Conduct  Hybrid  Training 

F.2.2  Transmit  Voice 

F.3.1  Stimulate  Sensors  on  Units 

F.3.2  Stimulate  Simulators 

F.3.3  Control  Simulations 

F.4. 1  Interface  with  Human 

F.4.2  Interface  With  System 

OA.2.11 

Produce  Feedback 

F.5.1  Store  Performance  Data 

F.5.2  Store  Event  Data 

OA.3 

Evaluate  Training 

OA.3.1 

Evaluate  Fleet 

F.2.1  Transmit  Feedback  Data 

OA.3. 2 

Certify  ESG/CSG  for 
Deployment 

F.2.1  Transmit  Feedback  Data 

OA.3. 3 

Certify  For  Entry  into 

Advanced  Phase 

F.2.1  Transmit  Feedback  Data 

OA.3. 4 

Evaluate  Type  Training 

F.2.1  Transmit  Feedback  Data 

OA.3. 5 

Evaluate  Doctrine/Tactics/ 
Procedures 

F.2.1  Transmit  Feedback  Data 

OA.3. 6 

Evaluate  CSG/ESG 

F.2.1  Transmit  Feedback  Data 
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D.  CAPABILITY  REQUIREMENTS  TO  FUNCTIONAL  REQUIREMENTS 
TRACEABILITY  MATRIX 


CapReq# 

Capability  Requirements 

Functional  Requirement 

CapReq.l 

Repetition 

CapReq.  1.1 

Provide  Training  Scenarios 

Req  3  Receive  Intel  Updates 

Req  5  Preprogrammed  Simulations 
Req  6  Modify  Simulations 

Req  7  Create  Simulations 

Req  1 1  Provide  Simulation  Storage 

CapReq.  1.2 

Run  simulations  independently 
between  units  and  simulators 

Req  8  Simultaneous  Simulations 

Req  9  Support  Multiple  Simulations 
Req  10  Simulation  Control 

CapReq.  1.3 

Train  with  limited 
communications 

Req  14  Communication 

CapReq. 2 

Feedback 

CapReq. 2.1 

Provide  Data  for  certification  and 
evaluation 

Req  12  Collect  and  Provide  Data 

Req  13  Aid  Cert  and  Eval 

CapReq. 2. 2 

Provide  Data  to  update  TTP 

Req  12  Collect  and  Provide  Data 

CapReq.  3 

Integration 

Req  1  Integrate  CSG/ESG  Units’ 
Weapon  Systems 

Req  2  Interface  with  Training 

Facilities  and  Simulators 

Req  4  Compatibility 

CapReq.4 

Webfires  Concept  Training 

CapReq.4.1 

In-port  and  At-sea 

Req  1  Integrate  CSG/ESG  Units’ 
Weapon  Systems 

Req  2  Interface  with  Training 

Facilities  and  Simulators 

Req  4  Compatibility 

CapReq.4. 2 

Multi-Unit  and  Unit  Training 

Req  1  Integrate  CSG/ESG  Units’ 
Weapon  Systems 

Req  2  Interface  with  Training 

Facilities  and  Simulators 

Req  4  Compatibility 
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CapReq# 

Capability  Requirements 

Functional  Requirement 

CapReq.4.3 

OFRP 

Req  1  Integrate  CSG/ESG  Units’ 
Weapon  Systems 

Req  2  Interface  with  Training 

Facilities  and  Simulators 

Req  4  Compatibility 

Req  12  Collect  and  Provide  Data 

Req  13  Aid  Cert  and  Eval 
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E.  FUNCTIONAL  REQUIREMENTS  TO  FUNCTIONS  TRACEABILITY 
MATRIX 


Req  # 

Requirement 

Basis  Of 

F.3.1  Stimulate  Sensors  on  Units 

F.4.2  Interface  With  System 

1 

Integrate  CSG/ESG  Units’ 
Weapon  Systems 

F.4.2. 1  Provide  Multi-Unit  Network 

F.4.2. 1.1  Connect  Units 

F.4.2. 1.1.1  Connect  Units  In-port 

F.4.2. 1.1. 2  Connect  Units  At-sea 

F.4.2. 2  Provide  Standalone  Network 

F.4.2  Interface  With  System 

Interface  with  Training 

F.4.2. 1  Provide  Multi-Unit  Network 

z 

Facilities  and  Simulators 

F.4.2. 1.2  Connect  Simulators 

F.4.2. 2  Provide  Standalone  Network 

3 

Receive  Intel  Updates 

F.1.4  Receive  Intel  Updates 

4 

Compatibility 

F.1.4  Receive  Intel  Updates 

F.1.1  Create  Simulation 

5 

Pre-Programmed  Simulations 

F.1.2  Store  Simulation 

F.1.5  Receive  Simulations 

6 

Modify  Simulations 

F.1.3  Modify  Existing  Simulation 

7 

Create  Simulations 

F.1.1  Create  Simulation 

F.3.1  Stimulate  Sensors  on  Units 

F.3.2  Stimulate  Simulators 

8 

Simultaneous  Simulations 

F.3.3  Control  Simulations 

F.4.1  Interface  with  Human 

F.4.1.1  Provide  Control  Display 

F.4. 1.2  Provide  HMI 

F.3.1  Stimulate  Sensors  on  Units 

F.3.2  Stimulate  Simulators 

F.3.3  Control  Simulations 

9 

Support  Multiple  Simulations 

F.4.1  Interface  with  Human 

F.4.1.1  Provide  Control  Display 

F.4.1. 2  Provide  HMI 

F.4.2. 1  Provide  Multi-Unit  Network 

F.4.2. 2  Provide  Standalone  Network 

10 

Simulation  Control 

F.3.3  Control  Simulations 

F.4.1  Interface  with  Human 

F.4.1.1  Provide  Control  Display 

F.4.1. 2  Provide  HMI 

11 

Provide  Simulation  Storage 

F.1.2  Store  Simulation 

12 

Collect  and  Provide  Data 

F.5.1  Store  Performance  Data 
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Req# 

Requirement 

Basis  Of 

F.5.2  Store  Event  Data 

13 

Aid  Cert  and  Eval 

F.5.1  Store  Performance  Data 

F.5.2  Store  Event  Data 

14 

Communication 

F.2.1  Transmit  Feedback  Data 

F.2.2  Transmit  Voice 

F.2.3  Transmit  Simulations 
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APPENDIX  E.  IRB  DOCUMENTATION 


A.  ORIGINAL  SEA-25  CAPSTONE  PROJECT  QUESTIONS 


Mission  (Tasks): 

1.  Define  the  scale  of  “web-fires”  in  the  realm  of  Air/Surface/Undersea/Cyber, 

a.  What  types  of  training  will  be  required? 

2.  Are  there  specific  Mission  Essential  Task  Lists  (METL)  items  for  this 
project  for  cross-domain  training? 

a.  What  are  the  prioritization  levels  of  these  METLs? 

b.  Who  are  the  primary  stakeholders  that  would  define  the  most  significant 
METLs? 

c.  Are  there  METLs  that  we  should  seek  to  focus  on  for  creating  training 
and  developing  tactics? 

3.  What  is  the  expectation  of  effective  tactical  training? 

Cross-Domain  Training: 

1.  What  are  the  existing  technologies  used  for  cross-domain  training? 

2.  What  are  some  challenges  to  incorporate  cross-domain  communications  with 
webfires? 

3.  What  training  systems  are  currently  available  for  incorporation  of  webfires? 

4.  What  current  capabilities  do  systems  provide  in  integrated  training? 

How  does  [insert  company/organization  name]  approach  cross-domain 
training? 

a.  Addressing  the  challenges/constraints  listed  above,  how  does 
the  respective  [company/organization  name]  incorporate  and 
adapt  to  these  challenges? 

b.  What  technology  is  capable  of  operating  in  a  webfires  environment? 

c.  Is  this  platform  specific  training  or  universal? 

5.  What  challenges  have  [insert  company/organization  name]  encountered 
in  cross-domain  training? 

a.  Particularly  from  the  perspective  of  joint  interoperability 

b.  Particularly  from  the  perspective  of  operating  in  an  integrated 
communications  environment 

6.  What  requirements  would  [insert  company /organization  name]  place  on  a 
system  operating  in  the  cross-domain  training  environment? 

a.  Do  these  requirements  align  with  the  requirements  that  we  have  been 
given  for  this  project? 

b.  Should  additional  requirements  be  added  to  help  scope-down  our  project? 

c.  How  are  these  requirements  prioritized? 

i.  What  are  the  Key  Performance  Parameter  (KPP)  requirements 
(aka  the  “non-  negotiables”)? 

7.  What  current  Navy/Joint  systems  support  integrated  webfires  training? 
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a.  Cooperative  Engagement  Capability  (CEC)? 

b.  Link  11/16? 

c.  Battleforce  Tactical  Trainer  (BFTT) 

Infrastructure  Security: 

1.  What  controls  are  made  to  prevent  an  adversary  from  gaining  access  or 
disturbing  these  training  systems? 

a.  Compromising  training  by  hacking  into  /  stealing  /  destroying,  etc. 

2.  What  are  the  challenges  in  communication  with  a  network  of  webfires 
especially  underwater  units?  How  is  bandwidth  to  be  controlled  if  there  are 
multiple  units  or  nodes  in  use  at  one  time  in  the  same  network? 

3.  How  will  these  training  platforms  maintain  comms  with  other  platforms  in 
EMCON  status? 

a.  What  are  the  challenges? 

b.  What  is  the  way-around? 

4.  What  will  webfires  be  capable  of  be  in  10  years? 
a.  All  domains  (Air/Surface/Sub- surface) 

5.  What  capabilities  will  the  training  system  have  in  terms  of 
communicating  with  other  platforms? 

6.  What  other  training  systems  are  currently  being  fielded? 

a.  EM  environment  (jamming)? 

b.  Long-range  communications  extension? 

c.  Weapons  delivery? 

d.  Stand-Alone? 

7.  What  is  the  envisaged  extent  of  this  system  for  U.S.  military  training? 
a.  Does  it  replace  manned  systems  or  complement  them? 

8.  What  are  the  challenges  experienced  by  users  when  dealing  with  cyber 
training? 

Technology: 

1.  What  sensors  are  currently  available  for  incorporation  into  the  training? 

Are  these  sensors  capable  of  operating  in  a  denied  environment?  How 
would  the  information  that  these  sensors  obtain  be  relayed  to  the  training 
system? 

a.  Once  information  is  gathered  by  a  sensor,  what  is  the  network  path  for 
delivery? 

2.  Are  we  seeking  to  strictly  use  existing  capabilities  and  repurposing 
AND/OR  develop  an  entirely  new  system? 

a.  Is  there  a  system  currently  being  fielded  that  supports  interoperability 
training  in  a  denied  environment?  Can  we  use  that  training  system 
as  a  template/model  for  our  future  defined  training  system?  (For 
example:  Does  our  prospective  training  system  mimic  other  systems 
such  as  NIFC-CA  or  other  Integrated  Fire  Control  (IFC)  related 
systems  or  BFTT?) 
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3.  Will  the  U.S.  Navy  have  technology  that  will  be  capable  of  passing 
large  amounts  of  data  through  the  water  that  will  have  the  speed  of 
kbps,  or  mbps,  not  the  current  bps? 

4.  What  are  the  considerations  to  develop  the  next  generation  of  C4ISR 
network  centric  architecture  to  support  cross-domain  training? 
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MSfl  Determination  Checklist 
last  updated  12/31/12 


'Instructions  Thu  form  K to  be  completed  by  the  IHB  Chair  o»  We-Choe  when  providvig  an  off  cal  RB  determination  or. 
whether  »  proposed  acbvrtv  meets  the  federal  define  ion  of  research  with  human  sublet's  accorddyg  to  31  Cf  R  219  After 
-cr-oer  mg  the  form  provide  to  the  RB  Administrator  The  IRB  Administrator  will  notify  the  investigators  and  file 
electronically. 
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Naval  Postgraduate  School 
Institutional  Review  Board 
Human  Subject  Determination  Request  form 


A  determination  form  may  be  submitted  to  The  IRB  when  a  researcher  is  unclear  if  a  proposed  activity  requ-w 
IRB  review  and  approval. 

To  receive  an  official  determination  from  the  IRB  submit  the  follow ng  documents  to  the  IRB  Administrator 
Rikki  Nguyen,  raonuveogncs  edu  at  least  two  weeks  prior  to  the  estimated  research  start  date. 

1.  This  form  completed  and  signed  by  the  prircipa-  investigator 

2.  A  copy  of  the  approved  research  proposal 

i.  A  copy  of  any  data  collection  tools  that  may  be  used  in  the  research  |e_g.  survey,  questionnaire, 
interview  questions) 


The  R8  w*  consider  the  attached  documents  and  if  additional  information  a  required  to  complete  the  review, 
the  prmopal  investigator  w«i  be  contactec 


A.  Research  Basics 


rate  of  the  Research 

Developing  warftghting  warning  to  leverage  web  fires 
concepts  and  technologies 

fr-’-V  1  it!3.  It.  '  T.r  f.^i~  .j ^ f 

Principal  Investigator 

Prof  fotis  Pane  jlias.  faculty  Advisor 

Co-  Invesligstorf  s) : 

ICDR  Daniel  OeCicco  |SCA  2S  cohort), LTs  Alvarer.  Arnett. 
Hook,  Thompson,  Weeks,  Yea  |SEA  2b  cohort) 

Student  Researchers- 

TDSI  students  |SC  13  cohort  1 

8.  Data  Collection 

1.  Will  the  activity  include  analysis  of  pfe-collected  data  > 


□  No 

~]  v«t.  Below  describe  the  nature  of  the  data  Including  data  variables)  and  whether 
the  data  will  contanpersonally  identifiable  information  | Pll)  or  personal  health 
Information  (PHI). 


2  Will  your  activity  include  interaction  with  people? 


a 


No 

res,  Below  describe  n-'u’  i.  iks  t>arlicipwnt|s|  will  be  asked  to  p*-lo--- 


Stakehdder  investigation  (who)  and  analysis  and  requirements  I  what)  for  deviHoplng 


wartighnrq  training  to  leverage  web  fires  concepts  and  technologies. 
Signature  PAPOUUAS  FOTIS  AJ  23 


Oate. 


0510071 


IHWI 

tM>  wim  if  9f)«a  ana 
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B.  MODIFIED  SEA-25  CAPSTONE  PROJECT  QUESTIONS 


Training  and  High-velocity  Learning 

1.  What  technologies  are  used  to  train?  (VR?  Simulators?  Classrooms?  Online?) 

2.  Are  the  scenarios  preset?  Is  Computer  Artificial  Learning  used  at  all?  Are  Human 
(Blue)  vs.  Human  (Red)  simulator  scenarios  used  at  all? 

3.  What  is  the  process  for  modifying  simulator  scenarios? 

4.  How  are  the  most  up-to-date  enemy’s  tactics  and  capabilities  integrated  into  current 
training? 

5.  How  do  the  instructors  interact  with  the  simulators? 

6.  How  is  training  performed  with  the  simulators? 

7.  How  is  doctrine  and  procedure  taught? 

Multi-Domain  Training  Architecture 

1.  What  documented  challenges  are  experienced  regarding  cross-domain  training? 

2.  How  are  other  communities  (such  as  SWOs/IAMD  WTI)  integrated  into  the  training? 

3.  How  does  _  (Company/Command)  integrate  with  other  training  facilities  and 

other  communities  across  the  Navy? 

Feedback  and  Future  Improvements 

1.  How  is  training  curriculum  feedback  reported  and  implemented? 

2.  How  is  simulator  HW/SW  feedback  reported  and  implemented? 

3.  How  is  feedback  used  to  update  training,  doctrine,  and  procedures? 

4.  How  is  feedback  incorporated  in  updating  the  warfighting  systems  and  training 
systems? 

5.  What  improvements  are  planned  for  the  next  generation  training  facility  or 
architecture? 

Current  Capabilities 

1.  What  is  the  current _ (Company/Command)  training  pipeline/architecture? 

2.  What  improvements  are  planned  for  the  next  generation _ (Company/Command) 

training  facility  or  architecture? 

Requirements 

1.  What  training  requirements  are  directed  to _ (Company /Command)  from  above? 

2.  What  pre-requisites  are  required  for  training  at _ (Company/Command)? 

3.  What  pre-requisites  or  requirements  are  there  to  initiate  integrated  training? 

4.  What  are  documented  requirement  gaps? 

Evaluation 

1.  What  are  the  documented  training  objectives  for  units/students? 

2.  How  is  the  units’/students’  performance  evaluated? 
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Training  Logistics 

1.  How  many  hours  a  day  do  students  spend  in  the  current  system? 

.  What  is  the  current  system  throughput/capacity? 

.  What  does  the  current  system  cost  to  build/purchase?  To  operate? 
.  How  are  simulators  integrated  with  other  simulators? 
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NPS  IRE 

HSR  Determination  Checklist 
last  updated:  2-2&-17 

instructions :  The  form  is  to  tie  completed  ay  the  IR  S  Chair  or  viee-Chair  when  providing  an  official  IR.S  eetermirabon  on 
whether  a  proposed  activity  meets  tre  teaeral  definition  of  research  with  numan  suojects  according  to  32  CFR  215.  After 
completirg  the  form  provide  to  ttie  IRB  Administrator  Tie  irb  Administrator  will  notrfy  tne  investigators  and  (tie  electronically 

Title  of  the  Activity  Developing  warfighting  training  to  leverage  web  fires  concepts  and  technologies 


Department:  Sys  Eng  Analysts 

Principal  Investigator  Potts  Papouilas 


Co- Investigators 


LCDfi  Daniel  DeClcco i  SEA  25  cohortl.LTs  Alvarez.  Arnett.  Hook.  Thompson.  Weeks.  Yee  ISEA 25  cohort; 
Student  Researchers:  _ 

Determination  Criteria 

1  Is  the  actanty  research?  Par  two  attnaty  to  t»  ntsoar^r  Batfi  (a)  am  fay  iraat  ee  answered  in  tne  ctfrmctM  Yes  No 

(a)  Is  the  activity  a  systematic  investigation?  K  D 


Does  the  activity  involve  the  use  or  numan  subjects?  ftv  nte  ocSruty  te  v**ot*9  Kumar.  sM/aas  fa)  ant  fo)  or  (q  must  oe 
'  answered vt the  ajfrmcmvt.  **  ° 

(a)  Is  the  activity  designee  to  coaect  information  about  a  living  individual?  □  ^ 


AB  questions  to  be  asked  by  the  invesbgrton  are  'about  what'  le.g.  "What  is  the  process  for  modifying  smular.ee  scenarios?'.  T-tow  are 
the  most  up-todate  enemy's  taebo  and  capacities  integrated  into  ament  training  T ;  ‘How  is  training  cumoiian  feedback  reported 
and  implemented?'  rather  than  'about  whom*  Therefore,  the  activity  o  deemed  not  human  subject  research. 

(b|  Does  the  activity  involve  interaction  with  a  person  or  persons?  15?  □ 


10  Ooes  the  activity  involve  the  use  of  ore-coi*ctec  irformation  that  is  Doth  private  and  personally  identifiable?  □ 


IRB  Determination 

The  attached  activity  involves  human  subjects  and  requires  IRB  review  and  KPS  President  approval. 


Yes  No 

□  K 


SHATTUCK.  LAWRENCE  Staton.. . 
IRB Chair/Vi™ Chair  GEORGE.  101 57S6825  ££“■==]£** 


21  Mar  2017 
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NPS  Instiaiaflnal  Rgi-jew  Board 

Human  Subject  Research  Determination  Request 


Purree 

To  request  the  16  review  proposed  activity  and  determine  if  it  involves  human  subject  research 
Prim  Instruct ions 

To  receive  an  official  detenrerution  submit  the  following  tc  IRB-nps.edu 
1  Determination  request  form  signed  by  the  Principal  Investigator  [Pt|.  Hate  The  PI  for  student  research  e  the  advisor 
2-  A  copy  of  the  research  proposal  or  statement  of  woik. 

3  Attach  arty  data  collection  tools  (ie.  interview  or  survey  questions,  etc). 

4  Submit  signed  determination  form  and  corresponding  documents  tc  IRB«-nps  edu  An  IBB  administrator  tail  contact  you  if 
additional  infoimation  a  needed. 

Tor  Questions  regarding  thn  form  or  process  send  an  e-mail  to  IRB-nps  adu  form  Updated  2-27-17 

A.  Research  Basics 

Title  of  the  Acttvttr  Developing  warfighting  training  to  leverage  web  fires  concepts  and  technologies 


Deportment:  Sys  Eng  Analysts  Currie  31 


Pima  pel  Investigator  Dr.  fobs  Papoulias 


Co- Investigators 


Student  Researchers:  LCDS  Daniel  DoCicco  i  SEA  25  cohortl.LTs  Alvarez.  Arnett.  Hook.  Thompson  Weeks.  Yee  ISEA  25  cohort; 

B.  Data  Collection 

1.  Wll  the  acttvtty  Include  the  use  of  pre-coAected  data?  Pre-collected  data  are  data  that  already  exist  such  as 
fitness  reports,  personnel  records,  training  records,  after  action  reports,  social  media  data.  Information  from  data  repositories, 
existing  survey  data,  ate 

K  No 

H  Ye s.  state  the  Mowing  below 

-  Describe  the  data  a  it  framing  records,  fitness  reports,  data  on  al  active  duty  by  speaality.  data  from  an  old  survey,  ato. 

-  State  the  approximate  number  of  records  you  wll  access. 

•  List  the  data  variables  to  which  you  wA  have  access.  Make  sure  to  indude  any  PB  or  demographics  contained  in  the  data 


2-  Wll  the  activity  Involve  interaction  with  people? 

□  No 

„  Yes,  describe  wfut  tasks  subjects  wiB  be  asked  to  perform  .take  a  suvey.be  interviewed,  participate  in  a  simulation,  play  a  game 
etc}  and  what  information  subjects  veil  be  asked  to  provide. 


Site  Visits  to  falkm.  NV  ind  San  Diego.  CA.  Demonstration  of  current  technologies  by  SMEs.  Interview  questions  as  attached. 


3.  Ha  proposal  or  statement  of  work  Is  not  available  describe  the  purpose  of  the  data  collection  and  how  the  data  wll  be  used. 

OPNAV  N9I T asking  statement  attached 
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